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

["Jeremy Volkman" <jvolkman@xxxxxxxxx>]

Stoyan,

Thanks for that pointer.  I hadn't caught that and I'll update my local patch set.  I've already opened a bug against this and I'll update it as well.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=182560

Cheers,
Jeremy

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

Hi Jeremy,

You are right. The patch you suggested will fix this problem.
For sake of completeness similar problem must be fixed in the
ComponentReference.unbind(...) method.
It removes the service reference before calling the component's unbind
method. So if you use locateService in your unbind methods, it will not
work. To fix this, the service reference has to be removed after invoking
the component's unbind method.

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#a10041824
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