RE: [equinox-dev] Bridging the plain Java and OSGi classloading worlds

["Michael Furtak" <mfurtak@xxxxxxx>]

Thanks very much for your thoughts! 

A reflective approach was in the back of my mind as well, but
unfortunately some of the methods I need to invoke accept objects of
types defined along side those services.

Luckily, the system packages approach seems to work - at least in my
simple tests!

-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.
 
-----Original Message-----
 
 

From: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Kemper David
Sent: Wednesday, August 19, 2009 8:43 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Bridging the plain Java and OSGi classloading
worlds

If the service defined and registered inside the OSGi framework is  
relatively simple, you might consider proxying your requests using  
Java reflection.

For example, if you've launched the OSGi framework using the new  
standard launch APIs, you will have access to the framework's bundle  
context, through which you can query the service. It will be returned  
as an object. If you know the expected signatures of the service  
methods, you can query its methods and invoke them without having code  
statically linked to it (which won't work because that service comes  
from a class loader inside OSGi). Reflection in effect bypasses the  
class loader.

I've done this myself for some simple cases, and the disclaimer is  
around the "relatively simple." If your service uses only JDK classes,  
this is pretty easy. It gets really messy really fast when you find  
yourself proxying multiple calls and queries.

In my case I queried the package admin service and refreshed packages,  
all without compiling against the PackageAdmin service class in my  
code. As a matter of fact, this was before the new OSGi framework  
launch API, and I created a URLClassLoader for the Equinox bundle, and  
instantiated and invoking the EclipseStarter from the outside. In  
other words, my code didn't even have access to org.osgi.framework.*...

I hope this sketch gives you some ideas.

/djk

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: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx 
> ] 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-embedd
ing.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-o
sgi/ 
>  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: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx 
> ] 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
> 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
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> <JavaOsgiBootstrapper.java><config.ini>
> _______________________________________________
> 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