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
[EMAIL PROTECTED]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
