Re: [equinox-dev] Declarative Services use case and inconsistencies betw

[Stoyan Boshev <s_boshev@xxxxxxxxxx>]

Finally, on third read, I saw your reference cardinality is 0..n, so your
bind method now makes sense to me :) . Also the changes in
ComponentReference.bind() and unbind() will have to be done.

Best regards,
Stoyan


Stoyan Boshev wrote:
> 
> Jeremy, you really made me read again certain parts of the DS spec ;) 
> 
> On second read I see something not clear to me in the code snippet of your
> bind method. According to DS spec (112.5.6 Activation), the component
> references' bind methods are called before calling the activate method of
> the component. The activate method is the place where the component gets
> its ComponentContext. Why do you use the component context in the bind
> method? 
> If I am right then there is no need to change anything in the bind and
> unbind methods of  ComponentReference.
> 
> BR,
> Stoyan
> 
> 
> Jeremy Volkman wrote:
>> 
>> Hi all,
>> 
>> We've recently switched to the ProSyst implementation of SCR in hopes of
>> overcoming many of the issues the old one had.  I've encountered an
>> implementation detail with the new version that affects one of my
>> standard
>> practices.
>> 
>> We use the whiteboard pattern in a bunch of places to register extensions
>> to
>> certain things (similar to the use of Eclipse's Extension registry). 
>> With
>> many of the extension objects, service properties are used to define some
>> metadata.
>> 
>> My general methodology is to declare a component that has a reference to
>> the
>> particular extension interface with cardinality 0..n.  I then create a
>> bind
>> method that looks something like this:
>> 
>> public void extensionAdded(ServiceReference extensionRef) {
>>   String extensionId = (String) extensionRef.getProperty("extension.id");
>>   String extensionName = (String)
>> extensionRef.getProperty("extension.name
>> ");
>>   IExtension extension = (IExtension)
>> componentContext.locateService("extensions",
>> extensionRef);
>>   registerExtension(extensionId, extensionName, extension);
>> }
>> 
>> It's necessary to have a bind method that takes type ServiceReference in
>> order to get these service properties.  AFAIK there is no way to get
>> service
>> properties after this method has been called other than storing them
>> locally
>> (there is no "locateServiceReferences()" method).
>> 
>> This used to work with the original implementation of SCR, however the
>> ProSyst implementation returns null when I call locateService(String,
>> ServiceReference) from within the bind method.  I've tracked the issue
>> down
>> to the following code at ComponentReference.java:250:
>> 
>> try {
>>   bindMethod.invoke(instance.getInstance(), params);
>> } catch (Throwable t) {
>>   Activator.log.error(
>>       "[SCR] Error while trying to bind reference "
>>        + this, t);
>>        // rethrow exception so resolver is eventually notified that
>>        // this component is bad
>>        // throw t;
>>  } finally {
>> ** serviceReferences.addElement(serviceReference);
>>    SCRUtil.release(params);
>>  }
>> 
>> The marked line is the issue.  The bound ServiceReference is being added
>> to
>> the ComponentReference's list of tracked ServiceReference after the bind
>> method is being invoked.  The locateService(String, ServiceReference)
>> method
>> fails to match the passed ServiceReference to this internal list, and
>> thus
>> returns null.  I can only assume that the original SCR implementation (
>> org.eclipse.equinox.ds) stores the ServiceReference before invoking the
>> bind
>> method.
>> 
>> I couldn't find anything in the DS spec that was clear about which way to
>> act in this situation, which is why I'm posting here and not in a bug
>> report.  Should I be able to locate the service object for a
>> ServiceReference from within the bind method?  If not, how can I ever get
>> service properties for DS-controlled references?
>> 
>> At this point I'm going to patch the code locally to add the
>> ServiceReference before invoking the bind method and hope that is the
>> correct behavior. :)
>> 
>> Thanks,
>> Jeremy Volkman
>> 
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Declarative-Services-use-case-and-inconsistencies-between-old-and-new-%28ProSyst-contributed%29-implementations-tf3573886.html#a10055775
Sent from the Equinox - Dev mailing list archive at Nabble.com.