2008/12/18 Richard S. Hall <[email protected]> > Jacques-Olivier Goussard wrote: > >> Sounds cool to be cutting edge, and I don't mind using those features in >> the >> launcher, which is felix specific. But IMHO, that makes building portable >> bundles (between equinox and felix for ex) a bit more difficult - felix >> users have >> to trust felix dev to modify the OSGi base only in backward compatible >> ways >> ... >> On my side for ex, I was coding against the official osgi.core.jar so >> didn't >> get >> this FRAMEWORK_STORAGE constant at compile time (which, again, is not >> a big pb for this specific case). >> Just my 2 cents, but I'd advocate to stick stricly to the spec and push on >> the >> OSGi comitee separately - but you're in charge ;) >> >> > > Actually, I debated how to go about introducing the constants (and some > additional interface), since I could also introduce them as Felix constants > (or interfaces) and move them later. I thought that sounded like a pain, so > I didn't do it. :-) The approach I took was to have Felix contain its own > modified versions of the interfaces. > > However, in the typical case, a bundle should not include felix.jar on its > build class path, since no bundle should depend on Felix. To compile, bundle > should be using org.osgi.core.jar, which is 100% pure. > > Perhaps it is not a perfect approach, but it didn't seem unreasonable > either. >
this sounds fair to me - same with the new service registry hooks, it lets people try out features before they're cast in stone without impacting those who compile against the released API -> richard > > /jog >> >> On Wed, Dec 17, 2008 at 2:41 PM, Richard S. Hall <[email protected] >> >wrote: >> >> >> >>> Jacques-Olivier Goussard wrote: >>> >>> >>> >>>> Thanks I'm looking into this. >>>> One thing I found in the code snippet for embedding Felix is a reference >>>> to >>>> Constants.FRAMEWORK_STORAGE. >>>> Is this an addition from Felix ? Looking at OSGi 4rev4.1 ( >>>> http://www.osgi.org/javadoc/r4v41/org/osgi/framework/Constants.html), >>>> there is no such constant. Does felix actually ships with a modified >>>> version >>>> of the OSGi spec ?? >>>> >>>> >>>> >>>> >>> Yes, it does. This is stuff being proposed for R4.2...cutting edge! ;-) >>> >>> -> richard >>> >>> >>> /jog >>> >>> >>>> On Wed, Dec 17, 2008 at 11:36 AM, Richard S. Hall <[email protected] >>>> >>>> >>>>> wrote: >>>>> >>>>> >>>> >>>> >>>> >>>>> For a while we had Felix' Logger using a LogService instance if one was >>>>> available, but this was leading to deadlocks since some logging was >>>>> occurring while holding locks and we cannot control what happens when >>>>> we >>>>> call out to a logger. As a result, we disabled this feature until it >>>>> can >>>>> be >>>>> resolved. >>>>> >>>>> There is still a possibility to get Felix to use a different logger by >>>>> passing a Logger instance into Felix' constructor via the configuration >>>>> properties, but this would require you to create your own Felix >>>>> instance, >>>>> see the following link for the property description: >>>>> >>>>> >>>>> >>>>> >>>>> http://felix.apache.org/site/apache-felix-usage-documentation.html#ApacheFelixUsageDocumentation-configuringfelix >>>>> >>>>> And the following link on how to launch Felix yourself: >>>>> >>>>> >>>>> http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html >>>>> >>>>> -> richard >>>>> >>>>> >>>>> Jacques-Olivier Goussard wrote: >>>>> >>>>> >>>>>> Hi >>>>>> Does anybody have an idea about how to capture felix logging in a file >>>>>> ? >>>>>> The org.apache.felix.framework.Logger class disables LogService >>>>>> logging >>>>>> and >>>>>> sends >>>>>> everything to System.out. >>>>>> The pb is that if felix is used as daemon (background server), logging >>>>>> is >>>>>> lost. >>>>>> I can redirect to a file, but I'd rather have all logging in one place >>>>>> (I >>>>>> use log4j internally) and >>>>>> inherit all the rollover and log appenders setup. >>>>>> Any idea to workaround this ? >>>>>> /jog >>>>>> >>>>> -- Cheers, Stuart
