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 ?

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
> 

Reply via email to