You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Christian Schneider <ch...@die-schneider.net> on 2017/02/24 14:32:12 UTC
[Discuss] Do we need to support other logging frameworks in felix
framework?
Currently felix framework uses reflection to allow other logging
frameworks. It is a quite complicated and still pretty limited approach.
As far as I know this is only used for karaf to hook in. So I propose to
only allow to choose jul as it is built in and we can avoid to add
dependencies as well as avoid to use reflection.
https://issues.apache.org/jira/browse/FELIX-5525
Karl reviewed the change and is generally positive but we would like to
get feedback from the community if this is a good idea.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [Discuss] Do we need to support other logging frameworks in
felix framework?
Posted by li...@io7m.com.
On 2017-02-24T16:30:06 +0100
Carsten Ziegeler <cz...@apache.org> 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.
As someone that pipes everything Felix says into an SLF4J
implementation running outside of the container, I agree wholeheartedly!
M
Re: [Discuss] Do we need to support other logging frameworks in felix framework?
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Feb 27, 2017 at 1:56 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Karl Pauls wrote
>>>> Yeah, something like this sounds like the way to go. I was wondering
>>>> if it isn't a possibility to overload the init() method on the system
>>>> bundle to optionally accept a logging object of some kind...
>>>>
>>> I think that's already too late. You want to have logging starting with
>>> the FrameworkFactory which creates the framework/system bundle.
>>> And I think this should not be part of the normal o.o.framework package,
>>> but rather just be part of o.o.framework.launch
>>
>> The init method is defined in the Framework interface which is in
>> o.o.framework.launch.
>
> Sure, but as you where saying system "bundle"... :)
The system bundle is the Framework :-D
>> Regarding the too late - its possible but in the case of Felix we do
>> almost nothing before init isn't called (and iirc, the framework
>> interface doesn't allow much either before that) but ymmv :-)
>>
> Now, I guess an implementation can do whatever it wants within
> FrameworkFactory until it returns a Framework object and in general I
> guess you want logging there.
I agree, thats why I said ymmv - I don't know what other frameworks
are doing out there.
Granted, what we currently do in Felix is more like what you are
suggesting - we allow the factory properties to be a Map<String,
Object> and we look for a logger property inside the Felix
constructor. If we can get a logger object we use it (via reflection)
- otherwise, we create our own system.out logger.
I guess we are in violent agreement here - it would be optimal if this
could be solved by the spec.
regards,
Karl
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
--
Karl Pauls
karlpauls@gmail.com
Re: [Discuss] Do we need to support other logging frameworks in felix
framework?
Posted by Carsten Ziegeler <cz...@apache.org>.
Karl Pauls wrote
>>> Yeah, something like this sounds like the way to go. I was wondering
>>> if it isn't a possibility to overload the init() method on the system
>>> bundle to optionally accept a logging object of some kind...
>>>
>> I think that's already too late. You want to have logging starting with
>> the FrameworkFactory which creates the framework/system bundle.
>> And I think this should not be part of the normal o.o.framework package,
>> but rather just be part of o.o.framework.launch
>
> The init method is defined in the Framework interface which is in
> o.o.framework.launch.
Sure, but as you where saying system "bundle"... :)
>
> Regarding the too late - its possible but in the case of Felix we do
> almost nothing before init isn't called (and iirc, the framework
> interface doesn't allow much either before that) but ymmv :-)
>
Now, I guess an implementation can do whatever it wants within
FrameworkFactory until it returns a Framework object and in general I
guess you want logging there.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [Discuss] Do we need to support other logging frameworks in felix framework?
Posted by Karl Pauls <ka...@gmail.com>.
>> Yeah, something like this sounds like the way to go. I was wondering
>> if it isn't a possibility to overload the init() method on the system
>> bundle to optionally accept a logging object of some kind...
>>
> I think that's already too late. You want to have logging starting with
> the FrameworkFactory which creates the framework/system bundle.
> And I think this should not be part of the normal o.o.framework package,
> but rather just be part of o.o.framework.launch
The init method is defined in the Framework interface which is in
o.o.framework.launch.
Regarding the too late - its possible but in the case of Felix we do
almost nothing before init isn't called (and iirc, the framework
interface doesn't allow much either before that) but ymmv :-)
regards,
Karl
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
--
Karl Pauls
karlpauls@gmail.com
Re: [Discuss] Do we need to support other logging frameworks in felix
framework?
Posted by Carsten Ziegeler <cz...@apache.org>.
Karl Pauls wrote
>>> Shouldn\u2019t 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 \u2026 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
>
> Yeah, something like this sounds like the way to go. I was wondering
> if it isn't a possibility to overload the init() method on the system
> bundle to optionally accept a logging object of some kind...
>
I think that's already too late. You want to have logging starting with
the FrameworkFactory which creates the framework/system bundle.
And I think this should not be part of the normal o.o.framework package,
but rather just be part of o.o.framework.launch
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [Discuss] Do we need to support other logging frameworks in felix framework?
Posted by Karl Pauls <ka...@gmail.com>.
>> 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
Yeah, something like this sounds like the way to go. I was wondering
if it isn't a possibility to overload the init() method on the system
bundle to optionally accept a logging object of some kind...
regards,
Karl
> Carsten
>
>> Regards
>> Felix
>>
>>> Am 24.02.2017 um 16:39 schrieb Christian Schneider <ch...@die-schneider.net>:
>>>
>>> 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
>>>>> cziegeler@apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
--
Karl Pauls
karlpauls@gmail.com
Re: [Discuss] Do we need to support other logging frameworks in felix
framework?
Posted by Carsten Ziegeler <cz...@apache.org>.
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\u2019t 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 \u2026 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 <ch...@die-schneider.net>:
>>
>> 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
>>>> cziegeler@apache.org
>>>
>>>
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [Discuss] Do we need to support other logging frameworks in felix
framework?
Posted by Felix Meschberger <fm...@adobe.com>.
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 <ch...@die-schneider.net>:
>
> 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
>>> cziegeler@apache.org
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: [Discuss] Do we need to support other logging frameworks in felix
framework?
Posted by Christian Schneider <ch...@die-schneider.net>.
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
>> cziegeler@apache.org
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [Discuss] Do we need to support other logging frameworks in felix framework?
Posted by Karl Pauls <ka...@gmail.com>.
> 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
> cziegeler@apache.org
--
Karl Pauls
karlpauls@gmail.com
Re: [Discuss] Do we need to support other logging frameworks in felix
framework?
Posted by Carsten Ziegeler <cz...@apache.org>.
Karl Pauls wrote
>> What about using the LogService once it is available to log. As this is
>> usually one of the first bundles (hopefully) this can then use whatever
>> logging mechanism is deployed - instead of trying to support all of the
>> available things out there.
>
> No. We tried that before and we had issues with this approach. It
> makes the most sense but it opens up deadlock possibilities in all
> sort of ways as we might be logging in places where we hold framework
> and classloading/resolving specific locks. Calling out to bundles at
> that point is a really bad idea, unfortunately.
Ok, yes, I see...too bad.
>
>> The current way works, but is not portable which means you have to do
>> other things if running a different framework - which I think is bad.
>
> I agree, but we can't really get around that. However, we did
> previously just used the osgi LogService interfaces and that was what
> we supported to have passed to the framework for logging (just not
> from a bundle).
>
But that can get into some strange class hierarchy problems, you need
the LogService class outside to pass it into the framework.
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.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [Discuss] Do we need to support other logging frameworks in felix framework?
Posted by Karl Pauls <ka...@gmail.com>.
> What about using the LogService once it is available to log. As this is
> usually one of the first bundles (hopefully) this can then use whatever
> logging mechanism is deployed - instead of trying to support all of the
> available things out there.
No. We tried that before and we had issues with this approach. It
makes the most sense but it opens up deadlock possibilities in all
sort of ways as we might be logging in places where we hold framework
and classloading/resolving specific locks. Calling out to bundles at
that point is a really bad idea, unfortunately.
> The current way works, but is not portable which means you have to do
> other things if running a different framework - which I think is bad.
I agree, but we can't really get around that. However, we did
previously just used the osgi LogService interfaces and that was what
we supported to have passed to the framework for logging (just not
from a bundle).
regards,
Karl
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
--
Karl Pauls
karlpauls@gmail.com
Re: [Discuss] Do we need to support other logging frameworks in felix
framework?
Posted by Carsten Ziegeler <cz...@apache.org>.
Christian Schneider wrote
> Currently felix framework uses reflection to allow other logging
> frameworks. It is a quite complicated and still pretty limited approach.
> As far as I know this is only used for karaf to hook in. So I propose to
> only allow to choose jul as it is built in and we can avoid to add
> dependencies as well as avoid to use reflection.
>
> https://issues.apache.org/jira/browse/FELIX-5525
>
> Karl reviewed the change and is generally positive but we would like to
> get feedback from the community if this is a good idea.
>
What about using the LogService once it is available to log. As this is
usually one of the first bundles (hopefully) this can then use whatever
logging mechanism is deployed - instead of trying to support all of the
available things out there.
The current way works, but is not portable which means you have to do
other things if running a different framework - which I think is bad.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [Discuss] Do we need to support other logging frameworks in felix framework?
Posted by Karl Pauls <ka...@gmail.com>.
> So maybe, in the end, supporting just JUL might be ok, particularly for SLF4J there is a wrapper which redirects JUL to SLF4J. So in my use cases, I can just deploy the JUL-to-SLF4J wrapper, set the property, and be done.
>
> I wonder, though, whether we should not keep the reflection feature for backwards compatibility.
In that case though, I would argue we don't need to add support for
JUL because the reflection is already working with JUL loggers
directly i.e., all one has to do is to put in a JUL logger into the
framework properties and it will be used. If we keep the reflection
anyways we might as well go with the reflection only me thinks...
regards,
Karl
> Regards
> Felix
>
--
Karl Pauls
karlpauls@gmail.com
Re: [Discuss] Do we need to support other logging frameworks in felix
framework?
Posted by Christian Schneider <ch...@die-schneider.net>.
On 24.02.2017 15:52, Felix Meschberger wrote:
> Hi Christian
>
>
>> Am 24.02.2017 um 15:32 schrieb Christian Schneider <ch...@die-schneider.net>:
>>
>> Currently felix framework uses reflection to allow other logging frameworks. It is a quite complicated and still pretty limited approach.
>> As far as I know this is only used for karaf to hook in. So I propose to only allow to choose jul as it is built in and we can avoid to add dependencies as well as avoid to use reflection.
>>
>> https://issues.apache.org/jira/browse/FELIX-5525
>>
>> Karl reviewed the change and is generally positive but we would like to get feedback from the community if this is a good idea.
> I have already commented on some aspects in the pull request. But now that you kick this discussion, let me throw in my 2 cents.
>
> First of all, I understand the \u201eproblem\u201c of providing a Logger instance which really binds the caller into the Felix API and thus breaks quite some assumptions of the FrameworkFactory launching method.
>
> Now for me the question is, whether JUL really is a good choice for logging or not. YMMV but I don\u2019t know many JUL uses. Most of the projects I have contact with are using SLF4J API and then mostly logback (or Log4J) implementation. Granted, there is quite some logging API variance (JUL, Log4J, SLF4J, Apache Commons Logging, probably some more) and deciding on which to use and which dependency to actually bind the framework on is a hard choice.
>
> So maybe, in the end, supporting just JUL might be ok, particularly for SLF4J there is a wrapper which redirects JUL to SLF4J. So in my use cases, I can just deploy the JUL-to-SLF4J wrapper, set the property, and be done.
>
> I wonder, though, whether we should not keep the reflection feature for backwards compatibility.
I don't think this feature is known widely. As far as I know it is only
used in karaf and I doubt anyone else uses it.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [Discuss] Do we need to support other logging frameworks in felix
framework?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Christian
> Am 24.02.2017 um 15:32 schrieb Christian Schneider <ch...@die-schneider.net>:
>
> Currently felix framework uses reflection to allow other logging frameworks. It is a quite complicated and still pretty limited approach.
> As far as I know this is only used for karaf to hook in. So I propose to only allow to choose jul as it is built in and we can avoid to add dependencies as well as avoid to use reflection.
>
> https://issues.apache.org/jira/browse/FELIX-5525
>
> Karl reviewed the change and is generally positive but we would like to get feedback from the community if this is a good idea.
I have already commented on some aspects in the pull request. But now that you kick this discussion, let me throw in my 2 cents.
First of all, I understand the „problem“ of providing a Logger instance which really binds the caller into the Felix API and thus breaks quite some assumptions of the FrameworkFactory launching method.
Now for me the question is, whether JUL really is a good choice for logging or not. YMMV but I don’t know many JUL uses. Most of the projects I have contact with are using SLF4J API and then mostly logback (or Log4J) implementation. Granted, there is quite some logging API variance (JUL, Log4J, SLF4J, Apache Commons Logging, probably some more) and deciding on which to use and which dependency to actually bind the framework on is a hard choice.
So maybe, in the end, supporting just JUL might be ok, particularly for SLF4J there is a wrapper which redirects JUL to SLF4J. So in my use cases, I can just deploy the JUL-to-SLF4J wrapper, set the property, and be done.
I wonder, though, whether we should not keep the reflection feature for backwards compatibility.
Regards
Felix
Re: [Discuss] Do we need to support other logging frameworks in
felix framework?
Posted by li...@io7m.com.
On 2017-03-02T11:18:14 +0100
Guillaume Nodet <gn...@apache.org> wrote:
>
> I don't think anyone uses the reflection stuff but Karaf. At least, I was
> the only one complaining about it when it was removed in 5.0 until I
> restored it in 5.6. If anybody does, please speak up now !
>
I pass in my own implementation of Felix's logger interface in order to
capture all of the framework's messages (and pipe them to SLF4J). Does
that count as use of reflection?
I actually wrote a small article on it a while back:
http://io7m.com/documents/brutal-felix-logging/
I don't mind API breaking changes as long as I can still capture all of
the framework's messages afterwards.
M
Re: [Discuss] Do we need to support other logging frameworks in felix framework?
Posted by Guillaume Nodet <gn...@apache.org>.
2017-03-01 23:56 GMT+01:00 David Jencks <da...@gmail.com>:
> I’m not sure what’s happening with the log service in R7, but in R6 it
> appears in the cmpn rather than core spec. It might be a bit confusing for
> the framework to contain the LogService interface but not export it.
>
> What exactly is wrong with using jul? Aren’t there lightweight adapters
> available for everyones choice of favorite log service?
>
I do agree. There's a simple standard which is provided by the JVM and
that people are used to plug into to provide their own backend using
logback or log4j for example.
I don't think anyone uses the reflection stuff but Karaf. At least, I was
the only one complaining about it when it was removed in 5.0 until I
restored it in 5.6. If anybody does, please speak up now !
The goal of FELIX-4845 <https://issues.apache.org/jira/browse/FELIX-4845> was
to clean up the code. It went a bit too far and removed the way to
actually have any saying over the logging framework. Using should solve
that problem and keep the code clean.
>
> david jencks
> > On Mar 1, 2017, at 1:36 PM, Christian Schneider <ch...@die-schneider.net>
> wrote:
> >
> > I just had an idea that might solve the problem of being flexible about
> the logger while not using reflection.
> >
> > How about using the LogService interface to provide an adapter to an
> arbitrary logger?
> >
> > We use the FrameworkFactory config to specify a logger. Either as an
> object if that is possible or as a class name given by the caller.
> > The logger must implement LogService and can then internally bridge to
> any logging framework.
> >
> > Using the well known LogService interface would allow to avoid
> reflection and we also do not need to change the spec. Of course the spec
> could still be changed to standardize how to specify a logger like this but
> we could easily already start just in felix.
> >
> >
> > Christian
> >
> >
> > On 24.02.2017 15:32, Christian Schneider wrote:
> >> Currently felix framework uses reflection to allow other logging
> frameworks. It is a quite complicated and still pretty limited approach.
> >> As far as I know this is only used for karaf to hook in. So I propose
> to only allow to choose jul as it is built in and we can avoid to add
> dependencies as well as avoid to use reflection.
> >>
> >> https://issues.apache.org/jira/browse/FELIX-5525
> >>
> >> Karl reviewed the change and is generally positive but we would like to
> get feedback from the community if this is a good idea.
> >>
> >> Christian
> >>
> >
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
>
>
--
------------------------
Guillaume Nodet
Re: [Discuss] Do we need to support other logging frameworks in felix
framework?
Posted by David Jencks <da...@gmail.com>.
I’m not sure what’s happening with the log service in R7, but in R6 it appears in the cmpn rather than core spec. It might be a bit confusing for the framework to contain the LogService interface but not export it.
What exactly is wrong with using jul? Aren’t there lightweight adapters available for everyones choice of favorite log service?
david jencks
> On Mar 1, 2017, at 1:36 PM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> I just had an idea that might solve the problem of being flexible about the logger while not using reflection.
>
> How about using the LogService interface to provide an adapter to an arbitrary logger?
>
> We use the FrameworkFactory config to specify a logger. Either as an object if that is possible or as a class name given by the caller.
> The logger must implement LogService and can then internally bridge to any logging framework.
>
> Using the well known LogService interface would allow to avoid reflection and we also do not need to change the spec. Of course the spec could still be changed to standardize how to specify a logger like this but we could easily already start just in felix.
>
>
> Christian
>
>
> On 24.02.2017 15:32, Christian Schneider wrote:
>> Currently felix framework uses reflection to allow other logging frameworks. It is a quite complicated and still pretty limited approach.
>> As far as I know this is only used for karaf to hook in. So I propose to only allow to choose jul as it is built in and we can avoid to add dependencies as well as avoid to use reflection.
>>
>> https://issues.apache.org/jira/browse/FELIX-5525
>>
>> Karl reviewed the change and is generally positive but we would like to get feedback from the community if this is a good idea.
>>
>> Christian
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: [Discuss] Do we need to support other logging frameworks in felix
framework?
Posted by Christian Schneider <ch...@die-schneider.net>.
I just had an idea that might solve the problem of being flexible about
the logger while not using reflection.
How about using the LogService interface to provide an adapter to an
arbitrary logger?
We use the FrameworkFactory config to specify a logger. Either as an
object if that is possible or as a class name given by the caller.
The logger must implement LogService and can then internally bridge to
any logging framework.
Using the well known LogService interface would allow to avoid
reflection and we also do not need to change the spec. Of course the
spec could still be changed to standardize how to specify a logger like
this but we could easily already start just in felix.
Christian
On 24.02.2017 15:32, Christian Schneider wrote:
> Currently felix framework uses reflection to allow other logging
> frameworks. It is a quite complicated and still pretty limited approach.
> As far as I know this is only used for karaf to hook in. So I propose
> to only allow to choose jul as it is built in and we can avoid to add
> dependencies as well as avoid to use reflection.
>
> https://issues.apache.org/jira/browse/FELIX-5525
>
> Karl reviewed the change and is generally positive but we would like
> to get feedback from the community if this is a good idea.
>
> Christian
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com