myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ertio Lew <ertio...@gmail.com>
Subject Re: Redirecting JUL Logging to other logging systems -- do we need to revisit our logging methodology?
Date Thu, 23 Aug 2012 18:38:48 GMT
Why doesn't Myfaces allows the flexibility to plug in your desired logging
SL4J implementation instead of restricting users to JUL/ Commons logging or
otherwise incurring the overheads of using bridgeHandlers etc ?!

On Thu, Aug 23, 2012 at 8:10 PM, Mike Kienenberger <mkienenb@gmail.com>wrote:

> Did you ever say something you really regretted?
>
> I really regret saying that I strongly preferred JUL over SL4J on the
> logging vote two years back[1].
>
> [1]
> http://mail-archives.apache.org/mod_mbox/myfaces-dev/200906.mbox/%3C8f985b960906060447g30bb216ew62102b39be2a1f27@mail.gmail.com%3E
>
> I am currently using the SLF4JBridgeHandler for JUL during
> development, and incurring the performance hits.
>
> Barring other events, my plans are to default back to JUL logging for
> production.
>
> How are other people handling this?  I know at the time of the
> discussion many people were switching to SL4J or still using log4j or
> JCL, all of which would have the same performance issues.
>
> Is it time to revisit our logging yet again, now that we know the
> theoretical flexibility of JUL didn't live up to the practical reality
> of using it?
>
> slf4j and myfaces
>
> http://mail-archives.apache.org/mod_mbox/myfaces-dev/200906.mbox/%3C2332f63b0906050818q6c74e615u2edc7cc2ec9f5101@mail.gmail.com%3E
>
> [VOTE] jul instead of commons-logging
>
> http://mail-archives.apache.org/mod_mbox/myfaces-dev/200906.mbox/%3C2332f63b0906091132y10cd0dadu4eb4a36dda6ae683@mail.gmail.com%3E
>
> [VOTE] use of jul or commons logging on myfaces core 2.0
>
> http://mail-archives.apache.org/mod_mbox/myfaces-dev/200910.mbox/%3Cf6c92360909301905g104297a5m3bba5fb3d0574fd@mail.gmail.com%3E
>
> https://issues.apache.org/jira/browse/MYFACES-2378
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message