felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: [Discuss] Do we need to support other logging frameworks in felix framework?
Date Fri, 24 Feb 2017 14:52:31 GMT
Hi Christian

> Am 24.02.2017 um 15:32 schrieb Christian Schneider <chris@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
> 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.


View raw message