Community
Participate
Working Groups
Currently, the ECF framwork runs on Equinox only. There has been community input that people would like to see the ECF bundles run on other frameworks. To do this, we will have analyze existing dependencies, and eliminate those that cannot be incorporated into other frameworks. In some cases this may reduce support for internationalization (i.e. NLS).
Do you talk ECF as a whole here or just core, remote services and discovery?
(In reply to comment #1) > Do you talk ECF as a whole here or just core, remote services and discovery? Good question. In my mind, the candidates for doing this: core shared object discovery remote services filetransfer datashare call api presence all providers and protocols *Not* *.ui plugins some examples/apps Of course, when we do this we will have to sequence/prioritize these. Adding helpwanted keyword also.
I (Scott) have been working some on this and have some progress to report on this bug...along with information about further needed changes. First, I've been removing references to the Equinox org.eclipse.osgi.util.NLS class in core and ECF remote services bundles...i.e: org.eclipse.ecf o.e.e.identity o.e.e.sharedobject o.e.e.provider o.e.e.discovery o.e.e.provider.discovery o.e.e.osgi.services.discovery o.e.e.osgi.services.distribution o.e.e.provider.zookeeper o.e.e.provider.jslp o.e.e.provider.jmdns o.e.e.provider.r-osgi o.e.e.datashare o.e.e.provider.datashare o.e.e.remoteservice o.e.e.remoteservice.rest o.e.e.remoteservice.soap o.e.e.provider.remoteservice o.e.e.server o.e.e.server.generic o.e.e.storage o.e.e.console The use of NLS in the above cases was not for UI strings, but rather for exception messages...and it's not necessary to have exception messages be translated via NLS. New/additional Equinox dependency issues. The following two remote services bundles have references to classes in org.eclipse.osgi.framework.eventmgr package: org.eclipse.ecf.osgi.services.distribution org.eclipse.ecf.provider.remoteservice org.eclipse.ecf.remoteservice.eventadmin Equinox bug 325624, if/when addressed, would eliminate this issue for ECF. In the short term, ECF may duplicate these Equinox classes within ECF to satisfy this bug/enhancement.
Created attachment 179351 [details] eventmgr supplement bundle The attached bundle allows ECF DOSGi to resolve and run on Apache Felix. It is extremely simple, it merely exports a copy of the o.e.o.framework.eventmgr package, which satisfies the imports of the ECF bundles. It has no dependencies. NB the bundle was built with Bnd. I'm not sure if it's possible to do the same thing with Eclipse PDE without copying the source code for package. The Bnd source is as follows: Bundle-Version: 3.6.0 Export-Package: org.eclipse.osgi.framework.eventmgr;version=${Bundle-Version}
(In reply to comment #4) > Created an attachment (id=179351) [details] > eventmgr supplement bundle > > The attached bundle allows ECF DOSGi to resolve and run on Apache Felix. > > It is extremely simple, it merely exports a copy of the > o.e.o.framework.eventmgr package, which satisfies the imports of the ECF > bundles. It has no dependencies. > > NB the bundle was built with Bnd. I'm not sure if it's possible to do the same > thing with Eclipse PDE without copying the source code for package. The Bnd > source is as follows: > > Bundle-Version: 3.6.0 > Export-Package: > org.eclipse.osgi.framework.eventmgr;version=${Bundle-Version} I wonder if such a bundle has broader usage among the OSGi community and thus host it as part of the Equinox project as an "official" supplement bundle.
(In reply to comment #5) > (In reply to comment #4) > > Created an attachment (id=179351) [details] [details] > > eventmgr supplement bundle > > > > The attached bundle allows ECF DOSGi to resolve and run on Apache Felix. > > > > It is extremely simple, it merely exports a copy of the > > o.e.o.framework.eventmgr package, which satisfies the imports of the ECF > > bundles. It has no dependencies. > > > > NB the bundle was built with Bnd. I'm not sure if it's possible to do the same > > thing with Eclipse PDE without copying the source code for package. The Bnd > > source is as follows: > > > > Bundle-Version: 3.6.0 > > Export-Package: > > org.eclipse.osgi.framework.eventmgr;version=${Bundle-Version} > > I wonder if such a bundle has broader usage among the OSGi community and thus > host it as part of the Equinox project as an "official" supplement bundle. Neil has already opened an Equinox enhancement request...see bug 325634. If you think it's better/more appropriate to have in separate bundle (rather than in common) then you might want to suggest than on 325624. Because this (eventmgr availability in equinox) appears to be the only remaining dependency for ECF running on non-equinox frameworks, perhaps we should add 325624 as blocking this bug. Any comments/thoughts before I do that?
Unfortunately there is a further problem. When starting up Felix I get the following error messages: Error: Could not parse XML contribution for "org.eclipse.ecf.provider.remoteservice//plugin.xml". Any contributed extensions and extension points will be ignored. Error: Could not parse XML contribution for "org.eclipse.ecf.provider//plugin.xml". Any contributed extensions and extension points will be ignored. Error: Could not parse XML contribution for "org.eclipse.ecf.sharedobject//plugin.xml". Any contributed extensions and extension points will be ignored. Error: Could not parse XML contribution for "org.eclipse.ecf.identity//plugin.xml". Any contributed extensions and extension points will be ignored. Error: Could not parse XML contribution for "org.eclipse.ecf//plugin.xml". Any contributed extensions and extension points will be ignored. Error: Could not parse XML contribution for "org.eclipse.equinox.registry//plugin.xml". Any contributed extensions and extension points will be ignored. This appears to be a general problem with using the Extension Registry on non-Equinox. I know this should work in theory but I don't know if anybody has actually done it in practice. My guess would be some difference in the XML parsers available from the JRE on Felix vs Equinox, but I don't have time to fully investigate this problem.
(In reply to comment #6) > Neil has already opened an Equinox enhancement request...see bug 325634. If > you think it's better/more appropriate to have in separate bundle (rather than > in common) then you might want to suggest than on 325624. .common works for me.
(In reply to comment #8) > (In reply to comment #6) > > Neil has already opened an Equinox enhancement request...see bug 325634. If > > you think it's better/more appropriate to have in separate bundle (rather than > > in common) then you might want to suggest than on 325624. > > .common works for me. No, .common would be a bad because it is also used on Equinox. Then the package would be exported both by .common and the system bundle. The supplement bundle is intended for use on non-Equinox framework, and it exports other packages that are otherwise exported only by the Equinox system bundle. It's the right place for this export.
WRT the registry issue described in comment 7, Neil has found a mailing list posting that describes this issue and provides an apparent work-around: http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg05302.html
(In reply to comment #10) > WRT the registry issue described in comment 7, Neil has found a mailing list > posting that describes this issue and provides an apparent work-around: > > http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg05302.html I confirm that Stuart's workaround does solve the registry issue. ECF still does not work completely when using the ECF Generic provider, but it appears to be an issue in Felix with Java serialization: Class not found sharedObjectID=StringID[org.eclipse.ecf.remoteservice.IRemoteServiceContainerAdapter] containerID=StringID[xzGaUflMm3U64NH9UVGIVzDfp5A=] java.lang.ClassNotFoundException: [Ljava.lang.Object; at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:814) at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.eclipse.ecf.provider.util.IdentifiableObjectInputStream.resolveClass(IdentifiableObjectInputStream.java:42) This doesn't look like an ECF issue at all. I will post a question about it on one of the Felix lists.
On further consideration I believe it is in fact an ECF bug, since the code in question calls ClassLoader.loadClass(). This method is not aware of the Java array class name syntax, i.e "[Ljava.lang.Object;" See the following Sun bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 Bottom line, change myLoader.loadClass(className) --> Class.forName(className, true, myLoader)
(In reply to comment #12) > On further consideration I believe it is in fact an ECF bug, since the code in > question calls ClassLoader.loadClass(). This method is not aware of the Java > array class name syntax, i.e "[Ljava.lang.Object;" > > See the following Sun bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 > > Bottom line, change myLoader.loadClass(className) --> Class.forName(className, > true, myLoader) I've changed IdentifiableObjectInputStream to use Class.forName/3 rather than classloader.loadClass and released this change to HEAD. This will be in ECF 3.4 and going forward, but it's too late to get into Helios maintenance release (3.3.1).
Created attachment 179426 [details] equinox/felix "adapter" bundle The fix described by Scott in Comment 13 works. I have been able to invoke a service running under Felix from a client that is running Equinox. Attached is a new bundle that implements both of the workarounds required, i.e.: * exports the eventmgr package * registers a SAXParserFactory service Note that this bundle must be started before the Extension Registry bundle, which can be achieved using start levels.
cool
(In reply to comment #15) > cool I would spell that with a capitol C ;)
Do you run the Felix instance from inside Eclipse via a .launch config? If so, we should be able to include this in our CI builds.
(In reply to comment #10) > WRT the registry issue described in comment 7, Neil has found a mailing list > posting that describes this issue and provides an apparent work-around: > > http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg05302.html Is it likely that this workaround won't be needed anymore in the near future?
FWIW: ECF's github [0] now contains everything that's necessary to run ECF remote services on Apache Felix with pax-runner. [0] https://github.com/ECF/ECF4Felix
The dependencies described by this bug have been removed, and ECF can run properly on Felix. See documentation here https://github.com/ECF/ECF4Felix for the steps to actually do so. Resolving as fixed.
