[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Bridging the plain Java and OSGi classloading worlds

My understanding is that the interfaces used (and dependent types therin) need to be loadable from oustide the OSGi engine and have the service import the same (external) interface. If you were to have one interface from outside, and one inside, they would complain. 

Another possibility would be to use sone kind of RMI or externalisation to get across the boundary, which would have the advantage of being usable for distributed access. Distributed OSGi might be useful for this.  

Alex 

Sent from my (new) iPhone

On 19 Aug 2009, at 21:32, "Michael Furtak" <mfurtak@xxxxxxx> 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-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: 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