> 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...
You can find some documentation about properties on this page: http://felix.apache.org/site/apache-felix-usage-documentation.html > 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)... Felix does implement the bundle interface -- hence, you can just do a BundleContext context = m_felix.getBundleContext(); then just use the context to install bundles (its the normal org.osgi.framework.BundleContext interface). > If you can provide assistance (off line / out of band), > that would be greatly appreciated, thanks, Craig Phillips, Praxis Best to redirect your questions to the felix user list (http://felix.apache.org/site/mailinglists.html). regards, Karl > ________________________________ > 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 > -- Karl Pauls [EMAIL PROTECTED] _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
