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 Thu, 20 Oct 2005 15:05:50 GMT
Hello Yoav,

just a short comment on the details, my major interested is documented at
the bottom:
> Yup, we know, that's why we did it that way for Tomcat.
> 
> > JCL could decide for one JVM instance to use a wrapper class to jul or
> to
> 
> The JVM instance is the wrong granularity: we want to enable per-webapp
> differences within the same JVM instance.
This is (and will be) not different for JCL users. The switch is _not_
using log4j or jul or JULI JVM wide. The switch is: 
if(jul is selected (auto or by config) && JULI present){
// do not use internal wrapper class
// but native jul and a cast to jcl.LOG
} else {
// use internal wrapper class for jul
}
This is a very optional part of JULI for me. If opions/argues/tests say
that it is not good, the two classes can be easily removed.
That is the same for slf4j.

> 
> > JULI is not a YALI - yet another logging implementation. It is an add-on
> to
> > the current java.util.logging.*
> 
> I'd argue it is YALI, but that's getting into semantic details.
The acronym has a very negative touch, but I brought it in...

JULI extends the freedom of choice for the user who is developing a new
program/API (jul is mainly not considered because of the poor set of JDK
delivered formatters/handlers/filters).
Existing users of jul have new opportunities with JULI.
Existing users of log4j will not migrate because the migration has no
benefit. Existing users of a wrapper have to check if they have a benefit or
not to add JULI to their environments.

> I would go ahead and publish it.  Feel free to advertise it on the logging
> and
> tomcat user lists, see what kind of feedback and adoption occur.  And I
> would
> also put in a BugParade RFE with these enhancements, if only so you can
> get
> some credit when Sun does this in JSE 5 Update 5 or 6.
I will remember this if an official vote ends with -1.
Out there: Are there other opinions?

I have spent several dozen hours to port, test, create the ant script,
document, check with checkstyle and findbugs etc.
The main sources of JULI are from Apache so I want to bring it to Apache.
I understand your argumentation (not meaning that I agree) but I hope
that members of the logging PMC will take the time for a vote (which has the
quality based on looking at the code, test once and not just reading the
small proposal HTML).

Best regards
Boris

Mime
View raw message