Petals Distribution

Switch from JUL to SLF4j with logback or equivalent

Details

  • Type: Task Task
  • Status: New New
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 4.2.4
  • Fix Version/s: None
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    We should move away from Java Util Logging.

    It is well known that

    using it is not recommended for performance and also classloading nightware reasons (see http://articles.qos.ch/thinkAgain.html for details on the matter).

    (THIS IS ACTUALLY WRONG!)
    It touches us through PETALSESBCONT-323 too for the classloading problems.

    Also it could simplify our homemade MDC code (the ExecutionContext that is in easycommons-thread).

    We should evaluate what to use, but slf4j and logback have a very good reputation in the java community.

    Show
    We should move away from Java Util Logging. It is well known that
    using it is not recommended for performance and also classloading nightware reasons (see http://articles.qos.ch/thinkAgain.html for details on the matter).
    (THIS IS ACTUALLY WRONG!) It touches us through PETALSESBCONT-323 too for the classloading problems. Also it could simplify our homemade MDC code (the ExecutionContext that is in easycommons-thread). We should evaluate what to use, but slf4j and logback have a very good reputation in the java community.
  • Environment:
    -

Issue Links

Activity

Victor NOËL made changes - Mon, 18 May 2015 - 15:15:24 +0200
Field Original Value New Value
Assignee Christophe DENEUX [ cdeneux ] Victor NOËL [ vnoel ]
Victor NOËL made changes - Mon, 18 May 2015 - 15:17:59 +0200
Summary Switch from Java Commons Logging to Log4j or SLF4J Switch from JUL to Log4j or SLF4J
Priority Blocker [ 1 ]
Description We should move away from commons logging.

It is well known that using it is not recommended for performance and also classloading nightware reasons (see http://articles.qos.ch/thinkAgain.html for details on the matter).
It touches us through PETALSESBCONT-323 too for the classloading problems.

Also it could simplify our homemade MDC code (the ExecutionContext that is in easycommons-thread).

We should evaluate what to use, but slf4j has a very good reputation in the java community.
We should move away from Java Util Logging.

It is well known that using it is not recommended for performance and also classloading nightware reasons (see http://articles.qos.ch/thinkAgain.html for details on the matter).
It touches us through PETALSESBCONT-323 too for the classloading problems.

Also it could simplify our homemade MDC code (the ExecutionContext that is in easycommons-thread).

We should evaluate what to use, but slf4j has a very good reputation in the java community.
Hide
Victor NOËL added a comment - Mon, 18 May 2015 - 16:36:20 +0200

the link I previously provided was about commons-logging, aka JCL, not JUL.

Anyway I still think we could move but maybe it is less critical than what I thought.

Show
Victor NOËL added a comment - Mon, 18 May 2015 - 16:36:20 +0200 the link I previously provided was about commons-logging, aka JCL, not JUL. Anyway I still think we could move but maybe it is less critical than what I thought.
Victor NOËL made changes - Mon, 18 May 2015 - 16:36:20 +0200
Priority Blocker [ 1 ] Minor [ 4 ]
Description We should move away from Java Util Logging.

It is well known that using it is not recommended for performance and also classloading nightware reasons (see http://articles.qos.ch/thinkAgain.html for details on the matter).
It touches us through PETALSESBCONT-323 too for the classloading problems.

Also it could simplify our homemade MDC code (the ExecutionContext that is in easycommons-thread).

We should evaluate what to use, but slf4j has a very good reputation in the java community.
We should move away from Java Util Logging.

It is well known that using it is -not recommended for performance and also classloading nightware reasons (see http://articles.qos.ch/thinkAgain.html for details on the matter)-.
It touches us through PETALSESBCONT-323 too for the classloading problems.

Also it could simplify our homemade MDC code (the ExecutionContext that is in easycommons-thread).

We should evaluate what to use, but slf4j has a very good reputation in the java community.
Victor NOËL made changes - Mon, 18 May 2015 - 16:37:55 +0200
Description We should move away from Java Util Logging.

It is well known that using it is -not recommended for performance and also classloading nightware reasons (see http://articles.qos.ch/thinkAgain.html for details on the matter)-.
It touches us through PETALSESBCONT-323 too for the classloading problems.

Also it could simplify our homemade MDC code (the ExecutionContext that is in easycommons-thread).

We should evaluate what to use, but slf4j has a very good reputation in the java community.
We should move away from Java Util Logging.

It is well known that
bq. using it is not recommended for performance and also classloading nightware reasons (see http://articles.qos.ch/thinkAgain.html for details on the matter).
(THIS IS ACTUALLY WRONG!)
It touches us through PETALSESBCONT-323 too for the classloading problems.

Also it could simplify our homemade MDC code (the ExecutionContext that is in easycommons-thread).

We should evaluate what to use, but slf4j has a very good reputation in the java community.
Hide
Victor NOËL added a comment - Wed, 8 Jul 2015 - 11:32:33 +0200

One advantage of switching to slf4j with something like logback as the implementation (since it is native) would be to better manage from which classloader the handlers (called appenders in logback) are instantiated.

This would make solving problems like PETALSDISTRIB-147 and thus PETALSESBCONT-323 much more cleanly!

Show
Victor NOËL added a comment - Wed, 8 Jul 2015 - 11:32:33 +0200 One advantage of switching to slf4j with something like logback as the implementation (since it is native) would be to better manage from which classloader the handlers (called appenders in logback) are instantiated. This would make solving problems like PETALSDISTRIB-147 and thus PETALSESBCONT-323 much more cleanly!
Victor NOËL made changes - Wed, 8 Jul 2015 - 11:33:22 +0200
Summary Switch from JUL to Log4j or SLF4J Switch from JUL to SLF4j with logback or equivalent
Description We should move away from Java Util Logging.

It is well known that
bq. using it is not recommended for performance and also classloading nightware reasons (see http://articles.qos.ch/thinkAgain.html for details on the matter).
(THIS IS ACTUALLY WRONG!)
It touches us through PETALSESBCONT-323 too for the classloading problems.

Also it could simplify our homemade MDC code (the ExecutionContext that is in easycommons-thread).

We should evaluate what to use, but slf4j has a very good reputation in the java community.
We should move away from Java Util Logging.

It is well known that
bq. using it is not recommended for performance and also classloading nightware reasons (see http://articles.qos.ch/thinkAgain.html for details on the matter).
(THIS IS ACTUALLY WRONG!)
It touches us through PETALSESBCONT-323 too for the classloading problems.

Also it could simplify our homemade MDC code (the ExecutionContext that is in easycommons-thread).

We should evaluate what to use, but slf4j and logback have a very good reputation in the java community.
Victor NOËL made changes - Wed, 8 Jul 2015 - 11:33:44 +0200
Link This issue blocks PETALSESBCONT-323 [ PETALSESBCONT-323 ]
Victor NOËL made changes - Tue, 31 May 2016 - 13:18:17 +0200
Link This issue depends on PETALSDISTRIB-256 [ PETALSDISTRIB-256 ]
Victor NOËL made changes - Tue, 31 May 2016 - 13:18:24 +0200
Link This issue depends on PETALSESBCONT-424 [ PETALSESBCONT-424 ]
Hide
Victor NOËL added a comment - Mon, 12 Sep 2016 - 11:22:35 +0200

FYI PETALSESBCONT-424 solved the MDC problem.

Now this issue is simply about switching to slf4j internally in Petals at least (components are more problematic because the JBI spec imposes the use of jdk Loggers).

Show
Victor NOËL added a comment - Mon, 12 Sep 2016 - 11:22:35 +0200 FYI PETALSESBCONT-424 solved the MDC problem. Now this issue is simply about switching to slf4j internally in Petals at least (components are more problematic because the JBI spec imposes the use of jdk Loggers).



People

Dates

  • Created:
    Tue, 5 May 2015 - 15:59:37 +0200
    Updated:
    Mon, 12 Sep 2016 - 11:22:35 +0200