[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Declarative Services use case and inconsistencies between old and new (ProSyst-contributed) implementations

Stoyan,

I realize now why ServiceReferences don't need to be stored unless a bind method exists; I had confused myself between the different types of locateService methods. 

You are correct that I need locateService within the bind method for 0..n cardinality references. I'll submit the patch that fixes both the bind and unbind methods.

Thanks,
Jeremy

On 4/18/07, Stoyan Boshev <s_boshev@xxxxxxxxxx> wrote:

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.

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev