Hi Jeff,
I'm trying to integrate Equinox as a JCA adapter into WLS 9.2
which, to the best of my knowledge, is not based on OSGi, as opposed to
WLS 10.0. Anyway, my goals are the following:
- Keep the application's main programming model, migrate to
OSGi only those very few yet very sensitive parts of the application
that change very often. This application is a _massive_ J2EE app which
has been in the works since 2001. We are still working on finishing the
first iteration.
- Statically define a set of service interfaces whose
implementation will be provided at runtime by Equinox. These interfaces
live in a jar which is visible to both the enclosing JCA adapter
module as well as Equinox. The packages these interfaces reside in are
listed among OSGi's system packages.
- Keep Equinox' class space(s) almost completely isolated
from that of the enclosing JCA adapter module's.
- Expose the org.osgi.framework classes - and later possibly
the packageadmin's classes - to the enclosing JCA adapter module so
that accessing OSGi services becomes possible. The org.osgi.framework
package is listed among OSGi's system packages.
When bootsrapping Equinox from inside the JCA adapter, I
create a new child first classloader as a child classloader of the
classloader that loaded the JCA module. This child first classloader
knows about the location of the org.eclipse.osgi.jar on the classpath
and first tries to load classes from this jar before delegating to the
parent classloader, thus isolating the Equinox implementation from the
enclosing JCA adapter module. This works like a charm:
JCA RAR ClassLoader --------->
service-interfaces.jar
|
|
ChildFirstBootstrapClassLoader
---------> org.eclispe.osgi.jar
Unfortunately, since the OSGi framework is included in
org.eclispe.osgi.jar, this also means that the org.osgi.framework
classes will be loaded by this child first classloader and will
therefore not be visible to the enclosing JCA adapter module. I tried
patching the child first classloader to not loading classes that start
with "org.osgi.framework" - I consider this solution an ugly hack - and
putting osgi_R4.jar on the JCA adapter module's classpath. This doesn't
work since it gives me a NoSuchMethodError: Equinox cannot find the
method Bundle.start(). I am no classloading expert but suspect that
there are two Bundle classes loaded. Of course, I could be totally
wrong.
Anyway, after several fruitless hours of debugging I decided
not to venture further down this path and opted for a solution that
uses reflection to gain access to the BundleContext returned from
EclipseStarter.startup(). This works yet feels a little clumsy. If
someone could point me to means of achieving my original goal
of sharing the OSGi API classes between Equinox and the enclosing JCA
adapter module, I would be grateful.
Cheers,
Olaf
----------------------------------------------------------------------------------------------------------
Hey Olaf,
The short answer is, No, such a distribution is not readily available.
The question in my mind is why do you need this? If you remove
the OSGi classes where will they come from? If you happen to be running
on an OSGi-based JEE app server then you could in theory get the
classes from the app server. To do this you should be able to play
around with the framework's parent classloader. That way the OSGi
classes would still be in the org.eclipse.osgi bundle but they would be
ignored in favor of the ones from the parent loader.
Jeff
Olaf Bergner wrote:
Hello,
I'm currently embedding equinox into a JEE app server and would like to make
the OSGi API visible to the enclosing application. Therefore, I need an
org.eclipse.osgi distribution that does not include the org.osgi.framework
classes. Does it exist?
Cheers,
Olaf
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
