Hi,

Currently Equinox assumes a one-one mapping with the class loader used to
load Equinox.  Equinox can be embedded multiple times into the same VM but
a separate class loader must be used each time to load Equinox.  This is
how the equinox is embedded into existing web containers.  See
http://www.eclipse.org/equinox/server/http_in_container.php

For the next OSGi specification we are looking to spec the way OSGi
Frameworks can be embedded/nested/peered.  Part of this specification may
mandate that multiple instances of a Framework must be able to be loaded
with the same class loader.  For the Equinox 3.5 release we will be
improving our story for embedding the Framework to align with the next
version of the OSGi specification.

Tom




                                                                       
  From:       Craig Phillips <[EMAIL PROTECTED]>                
                                                                       
  To:         OSGi Developer Mail List <[email protected]>        
                                                                       
  Date:       06/17/2008 10:59 AM                                      
                                                                       
  Subject:    RE: [osgi-dev] one OSGi container per JVM?               
                                                                       





Hi,

I guess I don't want to get too far off the OSGi path on a purely equinox
topic, for which I could post to the other list (although I had troubles
subscribing, but I think that's all straight); But, while we're on the
subject...

'EclipseStarter' methods are static... e.g., main(), startup(), run(),
isRunning(), shutdown(), getSystemBundleContext(), etc... ok, acknowledge,
static on a per [intended parent] class loader basis... hence, I guess that
means that I would be able to circumvent one equinox OSGi container per JVM
by setting up separate class loaders and then getting the equinox jar
loaded separately that way, and then I could invoke EclipseStarter.startup
()... and now I'm getting into a slippery slope, at the end of my expertise
in these matters, but I guess that's the only path that I could see...

Although, with all that said, there is the EclipseStarter.main() method,
for which I did not try [yet]; I successfully used the
EclipseStarter.startup() method; So, I could be mistaken; One interesting
thing I see with this mechanism (EclipseStarter) is what I'll call the "tap
in"... interesting...

I do aplogize for any ignorance on my part (what's the diff between main(),
startup(), and run()???)... the documentation is a bit lacking (sorry);
Felix has a good page on their stuff, but suffice to say I am going down an
equinox path for an immediate task at hand...

Not a big deal (I guess), just curious...  Thanks, kind regards (to quote
another), Craig

From: Richard S. Hall
Sent: Tue 6/17/2008 11:11 AM),
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] one OSGi container per JVM?

No, there is no such constraint and I don't believe that Equinox has
such a limitation, although their launcher might...

-> richard

Craig Phillips wrote:
> Hi, curiosity question... stemming from playing around with
> 'EclipseStarter'...
>
> I don't recall reading in the core spec a constraint that says there
> can be only one OSGi container per JVM...
>
> Just wondering/curious... Thanks, Craig Phillips, Praxis Engineering....
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

<<inline: graycol.gif>>

<<inline: ecblank.gif>>

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to