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 „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.
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
