logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boris Unckel" <boris.unckel....@gmx.net>
Subject Re: JULI proposal
Date Mon, 26 Sep 2005 06:03:31 GMT
Good morning,

Mark Womack wrote:
> I want to understand what niche JULI is filling here.  It extends the jdk
logging but uses log4j classes and implements JCL and SLF4J interfaces?  
Yes and no: JULI makes the feature gap between log4j and jdk logging
smaller. log4j classes were foundation of the port but most had to be
modified/redesigned to work. jdk logging is missing a good formatter,
with JULI it has the PatternFormatter (in log4j terms PatternLayout),
I could repeat for Handlers/Appenders and Filters.

If I knew that JCL and SLF4J would cause such confusion I would not have put
it in the initial version: With Shakespeare words "Much ado about nothing"
:-) For each JCL/SLF4J Interface exist two classes. Optional, removable, not
forcing the user even to know about it. Their advantage is that no wrapper
for the logging class is needed, a native implementation. Until there is no
support in the Wrapper Libariries (Factories) for JULI, they are useless.

Why would I want to use this instead of log4j or the jdk libraries?
If you want to use jdk-logging, you can also use juli to format your
logging output nice/usefull, rollover your logfiles after 3pm or 5MegaByte,
just as you configure it.
Again: No change to the interface of the jdk-logging for the user,
just configuration.

Different to log4j, but comparable with JCL, the native jdk-logging has a
bootstrap procedure, where the LogManager and other parameters can be
changend. This is the entry point of JULI.

> My mind is open, but it lacks information and background here.
Please have look at the provided sources.

> WRT specifics about incubator, etc...I think that the above should be
addressed first, then we can look at full subproject vs sandbox, etc.  To be
a full subproject there would need to be a community built up around it and
it would probably need to go through incubator (as part of that process). If
the effort is warranted and there is interest, then we can look at it.
Ok, without interested users/other committers a project does not make sense.
Maybe some tomcat people are interested, because the current production
tomcat 5.5 already contains the core of JULI.

> But we need to understand it all first.

>From a user's view:

import java.util.logging.Logger;

 * Sample for using JULI.
public class LoggingSample {

     * @param args
    public static void main(String[] args) {
        Logger myLogger = Logger.getLogger(LoggingSample.class.getName());
        myLogger.info("Hello World");



View raw message