Karl, I can't seem to find any javadoc for Felix, specifically 'Main'... I'm attempting to follow along but I could use some javadoc for the various constructs... I tried the felix web site, but nothing seems to jump out at me... I'm sort of coming to the conclusion that it's best to have a loaded config.properties ready to go versus programmatically getting a configProps loaded up... I managed to do a minimal m_felix.start() but I want to load the telnetd.jar to "poke around" but, alas, without javadoc, I think it'll be easier to provide a config.properties file (if I knew how to point 'Main' to that file)... If you can provide assistance (off line / out of band), that would be greatly appreciated, thanks, Craig Phillips, Praxis
From: Karl Pauls Sent: Wed 6/18/2008 6:54 AM To: OSGi Developer Mail List Subject: Re: [osgi-dev] one OSGi container per JVM? You might want to take a look at Apache Felix which is designed to be easily embedded. A good starting point is: http://felix.apache.org/site/launching-and-embedding-apache-felix.html as you can see there is no problem to just create several instances of Felix inside the same JVM. regards, Karl On Wed, Jun 18, 2008 at 12:00 PM, Colin Fleming <[EMAIL PROTECTED]> wrote: > Hi, > > The Knopflerfish runner has a similar problem (static methods), making > it very hard to embed as well. > > Cheers, > Colin > > 2008/6/17 Craig Phillips <[EMAIL PROTECTED]>: >> 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 >> > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Karl Pauls [EMAIL PROTECTED] _______________________________________________ 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
