Community
Participate
Working Groups
Unfortunately, we are seeing proxy services only when calling ServiceTracker.open(true). ----- see als this ----- After thinking about this bug, and realizing that you are using a ServiceTracker to track/discovery remote services I think this could be the following issue: The ServiceTracker class has two 'open' methods: public void open() and public void open(boolean trackAllServices) I suspect that you are currently using open() and with the Remote Services Admin it's necessary to use serviceTracker.open(true). See more about this below, but could you try opening with open(true) rather than open() and see if things then work for you? Given that your proxy/consumer discovery isn't happening for the generic provider either, I now don't believe this has anything to do with r-osgi localhost handling as I did yesterday. The RSA implementation has some new logic for proxy classloading as given in the OSGi 4.2 enterprise specification, section 122.5.6. For some reason that I'm not completely clear on, this proxy classloding logic seems to require the ServiceTracker.open(true) method to be used by clients rather than ServiceTracker.open() (because ServiceTracker.open() calls ServiceTracker.open(false)). The javadocs in ServiceTracker.open(boolean trackAllServices) for trackAllServices is this: * @param trackAllServices If {@code true}, then this * {@code ServiceTracker} will track all matching services * regardless of class loader accessibility. If {@code false}, * then this {@code ServiceTracker} will only track matching * services which are class loader accessible to the bundle whose * {@code BundleContext} is used by this * {@code ServiceTracker}. 'only track matching services which are class loader accessible' is the key part. I'm not clear on why the proxying logic in 122.5.6 seems to make the services 'not classloader accessible'...but it seems to do so. I'm going to consult with the folks responsible for the ServiceTracker and the spec to understand this better. In the mean time, please try ServiceTracker.open(true) in your code, and lets see if this fixes things for this use case. ----- and this ----- No this doesn't sound right. Using open(true) is dangerous precisely because of the risk of getting ClassCastExceptions -- it explicitly returns service instances that are incompatible with the client's classloader. The open(true) method is really only useful for clients that don't actually need to call the services they are tracking, e.g. because they are only interested in the metadata. If you are only seeing the proxy services when calling ServiceTracker.open(true), then it suggests something is going wrong. It sounds like a bug either in your code or in the framework's compatibility checking.
See thread on osgi-dev starting here: https://mail.osgi.org/pipermail/osgi-dev/2011-February/002972.html Seems this has blown up into a full-blown community issue...as the support for class compatibility checking of ServiceFactory in the framework is at issue: https://mail.osgi.org/pipermail/osgi-dev/2011-February/002993.html I'm going to let the discussion among the OSGi framework experts play out before I try to do anything different about this bug...as it's not going to be fixed by doing something minor...and I don't want to do something major until I know that it's going to work generally. Also...as a work around for the getServiceReferences...there is also getAllServiceReferences.
Setting this as assigned. As per the discussion thread beginning approximately starting here: https://mail.osgi.org/pipermail/osgi-dev/2011-February/003000.html I (Scott) should be able to create a 'dynamic dummy'...or a 'static' dummy extender bundle and make this issue go away (i.e. resolve it)...at least on Equinox 3.7M4. I'm still exploring the issue on that thread to attempt to provide a solution that will work with both Felix and with older versions of Equinox and Felix. It will take a few days (or perhaps longer) to finish this up...and I'm not sure what the level of support will be across Felix and older versions of the framework will be...but it should solve the ServiceTracker and the getServiceReference accesses (as both use the same framework logic for ServiceReference.isAssignableFrom for ServiceFactorys...and that's the issue here).
For me the workaround seems to be OK!
(In reply to comment #3) > For me the workaround seems to be OK! I'm very glad the workaround is working for you, but I'm now optimistic that I will be able to generally address this problem...at least for current/new versions of Equinox (and hopefully Felix also)...making the workaround completely unnecessary. This will be helpful for consumers, as once RSA is released (in ECF 3.5...in March), it would be good to avoid the need for consumers to use the workarounds (e.g. ServiceTracker.open(true) and getAllServiceReferences)...as of course everyone will use the normal API (e.g. ServiceTracker.open() and getServiceReferences).
As per the discussion on osgi-dev thread https://mail.osgi.org/pipermail/osgi-dev/2011-February/003000.html I've implemented a new bundle: org.eclipse.ecf.osgi.services.remoteserviceadmin.proxy, that is now used for registering the remote service proxy ServiceFactory. Once everything is back to normal wrt the build, this should fully fix this bug, at least on recent versions of Equinox (i.e. including and after 3.7M3) and Felix. There is more testing to be done, and this may upset the automated build for a while (since the new bundle has to be added to the osgi services feature, be built, be actually present for automated testing, etc). I'm not going to mark this bug fixed until all this churn is complete, and I've had a chance to test this new proxy bundle and it's behavior as described/discussed on the osgi-dev mailing list, but I'm quite certain now that this functionality will be present in ECF 3.5. But there may be some churn in the automated build/test over the next day. Just warning everyone.
With Eclipse 3.6.1 RCP ----- Caused by: java.lang.NullPointerException at org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractTopologyManager.getFrameworkUUID(AbstractTopologyManager.java:59) at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManager.getEndpointListenerScope(BasicTopologyManager.java:49) at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManager.start(BasicTopologyManager.java:64) at org.eclipse.ecf.internal.osgi.services.distribution.Activator.start(Activator.java:101) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)
+ this Exception if I put in some workaround for #6, I have included the proxy bundle to my launch: org.osgi.framework.BundleException: Exception in org.eclipse.ecf.internal.osgi.services.remoteserviceadmin.Activator.start() of bundle org.eclipse.ecf.osgi.services.remoteserviceadmin. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:806) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:374) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1067) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:561) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:546) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:459) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:440) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:337) Caused by: java.lang.IllegalStateException: RSA Proxy bundle (symbolic id=='org.eclipse.ecf.osgi.services.remoteserviceadmin.proxy') cannot be found, so RSA cannot be started at org.eclipse.ecf.internal.osgi.services.remoteserviceadmin.Activator.initializeProxyServiceFactoryBundle(Activator.java:81) at org.eclipse.ecf.internal.osgi.services.remoteserviceadmin.Activator.start(Activator.java:117) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) ... 11 more Root exception: java.lang.IllegalStateException: RSA Proxy bundle (symbolic id=='org.eclipse.ecf.osgi.services.remoteserviceadmin.proxy') cannot be found, so RSA cannot be started at org.eclipse.ecf.internal.osgi.services.remoteserviceadmin.Activator.initializeProxyServiceFactoryBundle(Activator.java:81) at org.eclipse.ecf.internal.osgi.services.remoteserviceadmin.Activator.start(Activator.java:117) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:374) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1067) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:561) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:546) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:459) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:440) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:337)
What happens if you try to start the proxy bundle manually?
Manual install (start) causes no problems.
Okay, changed start level, works now. Bug #6 is still present of course.
(In reply to comment #10) > Okay, changed start level, works now. Bug #6 is still present of course. I'm confused. Would you please summarize in prose what's happening in your environment? FYI...the proxy bundle *should* be started when the org.eclipse.ecf.osgi.services.remoteserviceadmin bundle is started. The NPE in getFrameworkUUID is probably 3.6.1-specific (as it's probably better associated with bug 337653)
(In reply to comment #11) > (In reply to comment #10) > > Okay, changed start level, works now. Bug #6 is still present of course. > > I'm confused. Would you please summarize in prose what's happening in your > environment? > > FYI...the proxy bundle *should* be started when the > org.eclipse.ecf.osgi.services.remoteserviceadmin bundle is started. > Yes, I'm sorry I had the proxy bundle to a startlevel +1 of rsa. > The NPE in getFrameworkUUID is probably 3.6.1-specific (as it's probably better > associated with bug 337653) Okay, this was a mistake then? This came up with updating to your "Partial fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=337673". This Exception (about the framework UUID) was not raised before. I will open a new bug for this. So this bug ramains for it's topic.
This bug is now fully fixed...i.e. ServiceTracker.open() can be successfully used for remote services...both for Equinox 3.7 stream (the new Equinox) and for pre 3.7 versions of Equinox. (See the discussion on osgi-dev pointed to in comment 5). I've tested on 3.7m4 and 3.6.1. I have yet to test on Felix (which should also work as per Equinox 3.7 is my understanding), but will try to do so as soon as possible.
Why doesn't org.eclipse.ecf.osgi.services.remoteserviceadmin require the .proxy bundle? Is this required by the wacky extender handling?
The fix does not work on oldEquinox() when the bundle exporting the service interface is not in the ACTIVE state but e.g. in the RESOLVED state.
(In reply to comment #13) > I've tested on 3.7m4 and 3.6.1. I have yet to test on Felix (which should also > work as per Equinox 3.7 is my understanding), but will try to do so as soon as > possible. FWIW: I have update ECF4Felix [0] to use ECF 3.5. Might help you with testing on Felix. [0] https://github.com/ECF/ECF4Felix/
(In reply to comment #14) > Why doesn't org.eclipse.ecf.osgi.services.remoteserviceadmin require the .proxy > bundle? Is this required by the wacky extender handling? In fact the proxy bundle is required...so I think I'll add it to Require-Bundle so the remoteserviceadmin is not resolved without it. (In reply to comment #15) > The fix does not work on oldEquinox() when the bundle exporting the service > interface is not in the ACTIVE state but e.g. in the RESOLVED state. The proxy bundle is started when the remoteserviceadmin bundle is started, so it should always be in the ACTIVE state.
> (In reply to comment #15) > > The fix does not work on oldEquinox() when the bundle exporting the service > > interface is not in the ACTIVE state but e.g. in the RESOLVED state. > > The proxy bundle is started when the remoteserviceadmin bundle is started, so > it should always be in the ACTIVE state. The exporting bundle is not the proxy bundle in this scenario, but a client code bundle on the consumer side that holds the interface of the remoted service (e.g. o.e.e.examples.hello).
(In reply to comment #16) > (In reply to comment #13) > > I've tested on 3.7m4 and 3.6.1. I have yet to test on Felix (which should also > > work as per Equinox 3.7 is my understanding), but will try to do so as soon as > > possible. > > FWIW: I have update ECF4Felix [0] to use ECF 3.5. Might help you with testing > on Felix. > > [0] https://github.com/ECF/ECF4Felix/ Thanks. Unfortunately, I don't think I'm personally going to be able to prioritize it before mid/late next week...since I have to create/deal with new feature, documentation, and other 3.5 final release issues.
(In reply to comment #19) > Thanks. Unfortunately, I don't think I'm personally going to be able to > prioritize it before mid/late next week...since I have to create/deal with new > feature, documentation, and other 3.5 final release issues. FYI: I have successfully invoked the IHello service served by a Felix/ECF 3.5 runtime.
(In reply to comment #18) > > (In reply to comment #15) > > > The fix does not work on oldEquinox() when the bundle exporting the service > > > interface is not in the ACTIVE state but e.g. in the RESOLVED state. The currently logic (in oldEquinox() case) calls rsaBundle.loadClass(serviceInterface)...RemoteServiceAdmin line 1474, with Dynamic-ImportPackage: * for the rsaBundle. Shouldn't this result in always moving the bundle exporting the service interface to the active state if it's in the resolved state?
(In reply to comment #21) > The currently logic (in oldEquinox() case) calls > rsaBundle.loadClass(serviceInterface)...RemoteServiceAdmin line 1474, with > Dynamic-ImportPackage: * for the rsaBundle. Shouldn't this result in always > moving the bundle exporting the service interface to the active state if it's > in the resolved state? Only if Bundle-ActivationPolicy is set to lazy for that bundle.
(In reply to comment #22) > (In reply to comment #21) > > The currently logic (in oldEquinox() case) calls > > rsaBundle.loadClass(serviceInterface)...RemoteServiceAdmin line 1474, with > > Dynamic-ImportPackage: * for the rsaBundle. Shouldn't this result in always > > moving the bundle exporting the service interface to the active state if it's > > in the resolved state? > > Only if Bundle-ActivationPolicy is set to lazy for that bundle. What can/could we do if the Bundle-ActivationPolicy is not set to lazy...and so the Bundle that holds the interface isn't started? Manually start it before using it's BundleContext for proxy registration?
(In reply to comment #23) <stuff deleted> > FYI: I have successfully invoked the IHello service served by a Felix/ECF 3.5 > runtime. That's great...thanks. You might want to make some more general announcement about ECF 3.5 remote services admin and Felix on ecf-dev...and/or blog...or both. I think ECF's new RSA impl could be very appealing to the Felix community. I will do this myself as well...but repetition is always good :).
(In reply to comment #23) > What can/could we do if the Bundle-ActivationPolicy is not set to lazy...and so > the Bundle that holds the interface isn't started? Manually start it before > using it's BundleContext for proxy registration? Manually starting the bundle might not be in the consumer's interest (e.g. Activator runs code with is not intended to run).
(In reply to comment #25) > (In reply to comment #23) > > What can/could we do if the Bundle-ActivationPolicy is not set to lazy...and so > > the Bundle that holds the interface isn't started? Manually start it before > > using it's BundleContext for proxy registration? > > Manually starting the bundle might not be in the consumer's interest (e.g. > Activator runs code with is not intended to run). Agreed this is possible (running code not intended to run)...but then what do you suggest doing? Without this bundle in active state, we can't use it's bundle context. So it either has to be started, or some other bundle context has to be used. Seems to me this is a reasonable choice. Note this is not a problem for Equinox 3.7 and Felix of recent vintage (since it's a workaround for Equinox pre-3.7m3).
(In reply to comment #26) > Agreed this is possible (running code not intended to run)...but then what do > you suggest doing? Without this bundle in active state, we can't use it's > bundle context. So it either has to be started, or some other bundle context > has to be used. Seems to me this is a reasonable choice. In case the bundle is not started, I'd suggest to fail gracefully logging an error. Then it's up to the consumer to decide.
(In reply to comment #27) > (In reply to comment #26) > > > Agreed this is possible (running code not intended to run)...but then what do > > you suggest doing? Without this bundle in active state, we can't use it's > > bundle context. So it either has to be started, or some other bundle context > > has to be used. Seems to me this is a reasonable choice. > > In case the bundle is not started, I'd suggest to fail gracefully logging an > error. Then it's up to the consumer to decide. FWIW, this is what it does now.
This fixed caused a regression in zoodiscovery: https://build.ecf-project.org/jenkins/job/C-HEAD-discovery.zookeeper.feature/112/
(In reply to comment #29) > This fixed caused a regression in zoodiscovery: > https://build.ecf-project.org/jenkins/job/C-HEAD-discovery.zookeeper.feature/112/ AFAIK the RSA code isn't even executed as part of the ZooDiscovery tests. %) I have fired up a new build manually. Lets see, if its "just" an intermittent problem.
(In reply to comment #29) > This fixed caused a regression in zoodiscovery: > https://build.ecf-project.org/jenkins/job/C-HEAD-discovery.zookeeper.feature/112/ I don't immediately know how any of the things done in relation to this bug could have anything to do with the zookeeper provider, but if you find that it is somehow associated with this bug then please let me know.
Hi all, I've launched the ecf4felix profile and the following st occurs: ___________________________ [SCR Component Actor] ERROR org.eclipse.equinox.event - [org.eclipse.equinox.event] The activate method has thrown an exception java.lang.IllegalStateException: ServiceFactory.getService() resulted in a cycle. __________________________ Is it related to the bug ?
(In reply to comment #32) > Hi all, > > I've launched the ecf4felix profile and the following st occurs: > ___________________________ > [SCR Component Actor] ERROR org.eclipse.equinox.event - > [org.eclipse.equinox.event] The activate method has thrown an exception > java.lang.IllegalStateException: ServiceFactory.getService() resulted in a > cycle. > __________________________ > > > Is it related to the bug ? I don't think so because here I also get this error but remote services work fine.
