logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yoav Shapira <yo...@apache.org>
Subject Re: JULI proposal
Date Wed, 19 Oct 2005 16:42:01 GMT
Hola,

> usecase(s), not as strategic discussion API vs API vs API.

It's both.

> My english in written and spoken language is not very good. The proposal was

Your English is just fine, don't worry about it.

> I cannot recognize if you have read the proposal and/or looked at the code
> base.

I've done both.

> As I understood in main it were classloading problems and not the need of
> special formatted/filtered output.

Its main goal is to get give Tomcat a working out-of-the-box logging
configuration that does not preclude the normal log4j or JDK 1.4 logging
use-cases.  Its other objective is to not try to do anything extra, like the
filtering things your code does, but only the bare minimum, and leave the rest
to more full-featured frameworks like log4 itself.

> 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.

The code and design are fine, it's the whole proposal that's bloat.  It's
unnecessary because the value added to Tomcat developers, log4j developers,
packagers, deployers, or users is significantly less than the confusion added.

> What do you mean with bridge? Bridge between which components?

Tomcat and JCL.

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

Great, but not the point, and can be done properly inside the frameworks
themselves for JSE 5.0 and log4j 1.3.

> It would be very easy for JCL to support JULI, they would recognize it by
> the system property.

This is the exact kind of trap that leads to nightmares in the Tomcat world
when some webapps want JULI and some don't but there's only one system
property.  This is exactly what I mean when I say from the Tomcat perspective
the current tomcat JULI is the bare minimum, and anything above it (numerous
things have been tried) has led us to complications.

> JULI is intended to be used by java.util.logging users.

I'd suggest your enhancements to the JDK team via their BugParade.  If they're
really as simple and valuable as you suggest, they should be integrated into
java.util.logging within the next JSE 5 update or so.

> 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.

An example of bloat again.

Again, please don't take this personally.  I'm trying to explain why I don't
like it.  Your code and design and thinking about performance are all great.

Yoav

Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com

Mime
View raw message