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

[Stoyan Boshev <s_boshev@xxxxxxxxxx>]

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#a10055521
Sent from the Equinox - Dev mailing list archive at Nabble.com.