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.
I would also suggest that you use the new OSGi standard for launching
frameworks, defined in RFC 132. You can find the doc in the 4.2 spec:
<http://www.osgi.org/download/r4-v4.2-core-draft-20090310.pdf> -
section 4.2.1. Far cleaner and simpler.
On Aug 19, 2009, at 1:32 PM, Michael Furtak wrote:
Hi Hal,
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?
Thanks in advance,
-Mike
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: [email protected] [mailto:[email protected]
] On Behalf Of Hal Hildebrand
Sent: Wednesday, August 19, 2009 3:18 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Bridging the plain Java and OSGi
classloading worlds
You can also check out:
http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html
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:
Sure. See http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/
for an in depth discussion by Costin of SS.
On Aug 19, 2009, at 12:08 PM, Michael Furtak wrote:
Hi Hal,
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?
Thanks,
-Mike
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: [email protected] [mailto:[email protected]
] On Behalf Of Hal Hildebrand
Sent: Wednesday, August 19, 2009 3:01 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Bridging the plain Java and OSGi
classloading worlds
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:
Hi all,
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?
Thanks,
-Mike
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.
_______________________________________________
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
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<JavaOsgiBootstrapper.java><config.ini>
_______________________________________________
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
