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 Wed, 19 Oct 2005 15:38:58 GMT

thanks for the first feedback. I regard this as discussion of the
usecase(s), not as strategic discussion API vs API vs API.
>Boris, thank you for writing this code, making the proposal, and raising
>relevant discussion issues.
>Please stick around and work with us log4j as well
>as JCL.  But this specific proposal I don't really like.
I will give some feedback for log4j 1.3 soon, during programming the port I
found some (potential) bugs, especially in the new rolling file

>I see this proposal as causing more confusion than value-add.
My english in written and spoken language is not very good. The proposal was
written under a certain pressure of having not much time.
I cannot recognize if you have read the proposal and/or looked at the code
I think there will be more people confused with my describition of JULI, so
the document has to be improved or rewritten before a formal vote starts.
Maybe someone can help.

>I don't like it with my Tomcat developer hat on,
>where we did exactly as much as we wanted to
>do in our JULI, and no more: this is definitely more.
I did not check the archives of the tomcat mailing lists in detail to lookup
exact needs in history of JULI.
As I understood in main it were classloading problems and not the need of
special formatted/filtered output.
Yes it is more and intended to be more, it is based on/contains the code
from the tomcat JULI.
JULI adds the features to java.util.logging which are missing to use it
comfortable, and flexible in output direction. If Tomcat developers/users
need that flexibility they have to decide on their own, I do not give any
advice or something.
It works by replacing the tomcat-juli.jar with an renamened juli-0.5.jar.

> I don't like it with my log4j developer hat on, as it's bloat.
I had to lookup the word: What is bloated up? jul? log4j? JULI itself? Or
did you look at the code and find ugly design? That would be really
interesting for me as I expect to learn a lot from input.

>I don't like it with my Jakarta Commons
>Logging hat, as it's yet another bridge leading to unnecessary user
The JCL implementation of JULI is not meant to be used directly by the user,
especially not the factory to create an logger.
What do you mean with bridge? Bridge between which components?

The JULI implemenation offers an performance advantage over the
jcl.JDK14Logger implementation:

jcl.JDK14Logger { ....
private void log( Level level, String msg, Throwable ex ) {

        Logger logger = getLogger();
        if (logger.isLoggable(level)) {
            // Hack (?) to get the stack trace.
            Throwable dummyException=new Throwable();
            StackTraceElement locations[]=dummyException.getStackTrace();
            // Caller will be the third element
            String cname="unknown";
            String method="unknown";
            if( locations!=null && locations.length >2 ) {
                StackTraceElement caller=locations[2];
            if( ex==null ) {
                logger.logp( level, cname, method, msg );
            } else {
                logger.logp( level, cname, method, msg, ex );
I do not want to post the full code[1]. It means that for any log entry an
exception is created.
Two possibilities: 
a) Remove the code and loose the functionality of recognizing the correct
b) Make the Appender/Handler know how he has to deal with an Logger
different from the default one.
It would be very easy for JCL to support JULI, they would recognize it by
the system property.
JULI offers the functionality of caller identification (including line and
file) without the performance issue for all calls within current level.

>And I don't like it as a user because it doesn't add anything and only
>confuses me.
JULI is intended to be used by java.util.logging users. jul suffers from
good handlers (aka appenders)
and is missing a pattern formatter. Filters are not so important to me but
others may be happy to
have them, so I ported the filters too.

>I agree the CLA, license, and SLF4J dependence are all easy issues that
>can be dealt with.
I am glad to discuss usecase, code... and not about the license issue (which
is also important for open source).

>But they're side points to the above.
You meantioned several groups of users which might be not interested in. I
am missing a statement to
java.util.logging users. java.util.logging users are not so much present in
current mailing lists.
The clue that they are not existing or have no needs in better
handler/formatter/filter possibilities
is not given by their absence in logging.apache.* and jcl.
jul has some advantages (like native I18N support) which can be accomplished
with wrappers or loghelper classes
for other logging APIs. Another advantage (from an API developer view) is
that you do not need to provide
any other jars "just for logging". (O.K. I assume JDK/JRE>=1.4). In later
runtime use people optionally can add JULI and have more



View raw message