Aha! The remaining key was removing the
OSGi bundle that contained my service interface, and as you said, forcing OSGi
to load them from the parent environment. I now have a successful service
object invocation from outside to within!
For anyone else that might want to try
this, it is good to know that the org.osgi.framework.system.packages.extra
property accepts version statements like a normal manifest import/export:
com.cra.myservice;version="1.0.0",com.cra.myservice.xml;version="1.0.0"
I’m sure this is not news to you,
but it was a nice discovery for me!
Thank you for your patient explanation and
guidance.
-Mike Furtak
THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records.
From: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On
Behalf Of Hal Hildebrand
Sent: Wednesday, August 19, 2009
6:24 PM
To: Equinox
development mailing list
Subject: Re: [equinox-dev]
Bridging the plain Java and OSGi classloading worlds
Okay, I'll go into a bit more detail.
At the base of the problem, the issue is that you have to have a common
class loader between the two environments. Inside the OSGi environment,
this is accomplished in only one of two ways:
- Boot class path
- System Bundle
A third mechanism, detailed by Costin in the SS post I provided
earlier, uses fragments of the System bundle, which amounts to #2.
Consequently, the classes you want to share between the environment
outside of OSGi, and within the OSGi container MUST originate from outside the
OSGi
container. What this means is that you cannot provide an OSGi bundle containing these classes, load them into the OSGi container, and expect them to be visible from outside the OSGi container. The equivalent, in JEE land, would be to expect a Servlet class loaded from within a WAR context to be visible in another JEE application scope - it just doesn't work and without bending both time in space in ways that even Cthulu would find a crime, essentially impossible.
In essence, this means that unless you're using the System bundle
fragments facade that Costin outlines, you won't be loading these shared
classes by loading them with OSGi bundles.
On Aug 19, 2009, at 1:32 PM, Michael Furtak
wrote:
Thanks for those references. They were
helpful. It feels like I’m close, but problems remain.
Also, I’m a bit confused as to
whether the noted techniques can help my problem. My understanding of the
system packages and boot delegation stuff is that it helps OSGi find classes
that are not explicitly exported from any of the OSGi bundles (i.e. java.*,
javax.* stuff, etc.)
My dilemma is somewhat the opposite.
I’m originating from Java, outside of the OSGi environment, but want to
call objects created inside of OSGi. Of course, this leads to a
ClassCastException when I get the service object and try to refer to it by its
interface as loaded in Java land.
I’ve attached my source w/ some
class/package names changed to protect the innocent. Also attached is my
config.ini file. Without the org.osgi.framework.system.packages.extra
directive, the ClassCastException occurs. With it, I don’t get a callback
on my ServiceTrackerCustomizer’s addedService() method.
Do you have any further thoughts?
THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM
IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL
AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended
recipient, your use of this message for any purpose is strictly prohibited. If
you have received this communication in error, please delete the message and
notify the sender so that we may correct our records.
note the section "Creating and Configuring the
Framework Instance", and the use of the property
"org.osgi.framework.system.packages.extra" which makes this a bit
easier. Works the same way with Equinox.
On Aug 19, 2009, at 12:13 PM, Hal Hildebrand wrote:
On Aug 19, 2009, at 12:08 PM, Michael Furtak wrote:
Thanks very much for your reply. I’m
heartened that you’re confident in this possibility. Is there any
documentation for the option you mention that I can refer to?
THIS MESSAGE IS INTENDED FOR THE USE OF
THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS
PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If
you are not the intended recipient, your use of this message for any purpose is
strictly prohibited. If you have received this communication in error, please
delete the message and notify the sender so that we may correct our records.
sure, you just have to have a class loader
in common. The way this would work is to modify the exports of the System
bundle (an option when starting the framework in Equinox) to export the classes
from the base class path you need. Then there is no class loader issues,
as they're both using the same.
On Aug 19, 2009, at 11:56 AM, Michael Furtak wrote:
I am using the
EclipseStarter.startup(…) method to bring up the Equninox framework from
within a plain ol’ Java application. My question is this:
Is it possible to allow the plain
ol’ Java environment to get and call service objects from the OSGi side?
I know their respective classloader environments are disjoint, but is there any
hope at all of bridging them? Has anyone been dumb/crazy enough to want to do
this?
THIS MESSAGE IS INTENDED FOR THE USE OF THE
PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED,
CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not
the intended recipient, your use of this message for any purpose is strictly
prohibited. If you have received this communication in error, please delete the
message and notify the sender so that we may correct our records.
<JavaOsgiBootstrapper.java><config.ini>
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
|