[jira] [Commented] (DELTASPIKE-938) Enable the use of slf4j for logging without jul2slf4j-bridge

["John J. Franey (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DELTASPIKE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14942401#comment-14942401 ] 

John J. Franey commented on DELTASPIKE-938:
-------------------------------------------

Case closed, I know, but, if these are your reasons, they are contestable.  With due respect, I submit, 1: its not 'easy' to route one to the other, 2: JUL is not more minimal than slf4j, 3: slf4j is not the root cause of classloader clashes.

1) Its not easy to re-route jul....depending on the meaning of 'easy'.  Routing jul method calls to slf4j is not as easy as routing slf4j calls to jul.  Both are 'easy' compared to say writing deltaspike, but only one is easier:
   The slf4j implementation can be easily replaced by classpath...a different implementation jar for the same api.  The jul implementation cannot be replaced...bridge is always required.  slf4j is easier.
   The SLF4J->jul path tests log level BEFORE creating the jul log event.  The jul->SLF4J bridge ctor-copies the log from jul structure to slf4j structure BEFORE testing the log level.  SLF4j->jul is easier.

2) sfl4j is not a 'framework', its a facade.  It is 'minimal'.  It is less than JUL.  JUL is a 'logging framework' not an API.  The JUL API can NEVER be used in isolation of the JUL framework.  There is a distinction between a 'facade' and a 'framework'. JUL and slf4j are NOT even the same kind of thing!

A library bound to a logging framework (e.g, JUL, log4j) levies an imposition on the users of the library.  From the library developers' perspective, JUL appears light and minimal (no need to add a jar, no interface incompatibilities, etc...).  From the library USER's perspective, imposition of the logging framework is still small compared to other work, but not the most minimal.  By imposing the 'logging framework', the library user must deal with it, by integrating it into the 'logging framework' in use by his application.  What happens, in your opinion, if in addition to deltaspike (imposing JUL), my application also used a library imposing log4j, and another that imposed something else (log4j++ maybe).  Sure, its 'easy' to mitigate, but in this case, if all libraries used slf4j, it would be easiest for me, your customer.  Get it?  This is how slf4j is more minimal....it doesn't impose a logging framework on your customer.  Your customer is free to choose the framework.  Deltaspike itself becomes more minimal.

3) Class loader clashes are caused by bad packaging.  In turn, bad packaging reveals compatibility problems.  Its always a bad decision to package two versions of api jars for any runtime.  Any code written to the later version can inadvertently get the older version....even if the api are compatible, that is bad.

(In my opinion, class loader clashes are desired because they reveal bad packaging which otherwise may go unnoticed).

What we developers want is 'forward compatibility'....old code written to an old api can dynamically link to a new version of the api.  'backward compatibility' is rarely a goal: new code, written to a new api, using an old version of the api.  SLF4J does 'forward compatibility' very well.




> Enable the use of slf4j for logging without jul2slf4j-bridge
> ------------------------------------------------------------
>
>                 Key: DELTASPIKE-938
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-938
>             Project: DeltaSpike
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.4.1
>            Reporter: Jörg Sesterhenn
>
> As a developer i want to use slf4j in my application to be able to choose an loggingimplementation at a later point in time.
> deltaspike should suport this without having me use the jul2slf4j brigde wich has performance warnings attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)