Felix Meschberger wrote > Hi all > > Hmm, thinking a bit more about this and looking at the FrameworkFactory class > which is targeted at launching frameworks in an implementation independent > manner, I wonder, whether logging being a crucial function in each and every > application should not get special treatment on a specification level ? > > Shouldn’t we try to get the specification extended to define a well known > property for configuration map handed to the FrameworkFactory.newFramework > method which names some sort of logger ? > > Unfortunately that configuration map is Map<String, String> so the logger > itself cannot be provided … but maybe some factory class name or so ? >
Yepp, something in this direction was my suggestion as well - doesn't work with the map due to String objects,but we could add a new method. I already created an issue for this in the OSGi issue tracker, so we will discuss this in one of our next calls I hope Carsten > Regards > Felix > >> Am 24.02.2017 um 16:39 schrieb Christian Schneider <[email protected]>: >> >> The problem is that we can not directly depend on the felix framework from >> karaf as we must be able to switch between equinox and felix. >> So the karaf starter may not have a direct dependency on felix framework. >> >> So if the log service interface would be in an OSGi spec jar it would be >> fine. >> >> Christian >> >> On 24.02.2017 16:33, Karl Pauls wrote: >>>> I guess it would be nice if the launcher api had a simple logger >>>> interface which you could implement and pass into the framework factory. >>>> Then everyone can implement this in any way they want and this would be >>>> portable across framework implementations. >>> I'm fine with that as well. Basically, just replace the current >>> reflection calls one-to-one with real methods (which will look like >>> the OSGi LogService by-and-large). >>> >>> So karaf and others would just have to wrap their JUL logger with a >>> simple Felix LogService decorator. >>> >>> regards, >>> >>> Karl >>> >>>> Carsten >>>> -- >>>> Carsten Ziegeler >>>> Adobe Research Switzerland >>>> [email protected] >>> >>> >> >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com >> > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
