logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: UI comments? Use of 1.4 JDK and LoggingEvent properties
Date Sat, 19 Apr 2003 17:29:44 GMT
At 09:40 AM 4/19/2003 -0700, Scott Deboy wrote:
>I've written a logging UI that takes the good ideas implemented by Oliver 
>Burn in Chainsaw and adds features that I felt were needed to stop logging 
>to both text files and Chainsaw (wanted to get away from having to use 
>grep on log files)...
>There are two issues I would like the dev list's input on.
>I've included support for regular expression-based display and colorizing 
>filters but built-in support for regexp is only recently available with 
>the 1.4 JDK in the java.util.regex package.
>Question:  Should I remove the 1.4 dependency?  Is the benefit of 1.4 
>users not needing to install a separate regexp package (ORO) outweighed by 
>the usefulness of a 1.2 compiled UI and the separate download requirement?

Installing a jar file is not that difficult. Taking the extra jar file
argument to the extreme, since JDK 1.4 already contains a logging
package, there would be no sense in continuing to work on log4j
because its use entails installation of at least one extra jar
file. Of course that is a bit too radical an argument and if it were
true, we would not be having this discussion.

Now, claims for 100% compatibility with JDK 1.x are much stronger when
the code compiles with JDK 1.x. (If the compiler says it then it must
be true.) When we say log4j is JDK 1.2 compatible we mean runtime AND
compile time. When a user reports a log4j bug when running under JDK
1.3, it is significantly easier for the user to hunt the bug if the
code compiles under the same JDK. Switching between JDKs is possible
but a pain.

Given that log4j's primary task is to facilitate problem discovery, it
is paramount that log4j itself be as bug-free as humanely
possible. Thus, it makes no sense to introduce elements which
undermine this primary directive. In the past, we have avoided
introducing nifty features because we could not guarantee their
correct execution in all Java environments.

In the long run, it is simpler to say that chainsaw requires
jakarta-oro than trying to explain that jakarta-oro is required only
in JDKs prior to 1.4, and that in JDK 1.4 and later the
java.util.regex implementation is used. For people who run
into problems with JDK prior to 1.4, bug identification becomes more
difficult if log4j code needs to be compiled with 1.4 and only
"runtime-tested" with prior JDKs.

We had a similar situation with the MDC class which required JDK 1.2
to compile but could also "run" under JDK 1.1. Even if the
circumstances are not identical, the conclusion was that given our
limited resources it was more reasonable to require JDK 1.2
compatibility and drop adaptable JDK dependent behavior. See
http://marc.theaimsgroup.com/?t=103471060500008&r=1&w=2 for more
details on this vote.

It is all a question of priorities and resources. If the first
priority is to have simple (hence maintainable) code and resources are
constrained, then my suggestion would be to stick to 1.2 and drop 1.4
specific features. If we had 47 billion dollars cash at our disposal,
then things would look somewhat different.

>If neither are available, the app will still work - the user just loses 
>the ability to define regexps for filtering - partial text matching is 
>used instead.
>Should the UI be jarred separately?  I understand the benefit of having a 
>UI and the core classes available as a single download.

Yes, we had a debate about this some time ago. In log4j 1.3, LF5 and
chainsaw will be available as separate jars. For details pelease see:


>There are other benefits to supporting 1.4 - better performance of the 
>collections classes and a scrolling JTabbedPane come to mind.

>One of the main differences between the new UI and Chainsaw is the new 
>UI's support for event 'routing' to separate panels in a 
>JTabbedPane.  Panels in the JTabbedPane are uniquely identified by the 
>source machine and a user-defined 'application' property.

Unless I have something, your changes should be integrated into chainsaw. I 
can't imagine any benefits of having a third log GUI.

>To route the events to separate panels, two properties are added to the 
>LoggingEvent by the appenders - 'log4japp' and 'log4jmachinename'.
>The log4japp property is a JavaBeans-style property on the Socket and 
>UDPAppenders which can be configured through a param on the xml file.
>If a log4japp system property exists, the appender property and the system 
>property are combined - provides the ability to define the app name at runtime.
>The machinename property is added automatically.  Only the first part of 
>the FQDN is used if it can be resolved.  If it can't be resolved, the IP 
>address is used.
>Question:  Are these 'universal' properties (useful to anyone consuming 
>loggingevents), and therefore setting these properties on all 
>loggingevents via the appender is OK?  If not, is there a recommendation 
>on how to get them added when the target is known to be the logging UI?

Setting these properties can be appender options set at config time.

>If neither property are provided in the loggingevent (for example, if 
>someone is using a current log4j.jar without updated appenders), all 
>events end up in the UI on a tab named 'unknown'.


Ceki  For log4j documentation consider "The complete log4j manual"

To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

View raw message