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: Interesting thread about commons-digester and other component s
Date Mon, 13 May 2002 18:09:46 GMT
At 09:46 13.05.2002 -0700, Mark Womack wrote:
>I have not had a chance to read in complete detail, but some initial
>thoughts:
>
>1) I do think that having a "special" version of the digester is going to be
>a long-term headache.

There is no major technically difficulty in implementing the digester clone 
within
log4j. I have already  started to seriously think about implementing it. 
More on this
later today or tomorrow.

The issue is more social than technical. Unless there is a good reason to
do it, it's pretty uncool to rip off someone else's code. Fortunately, in this
case the authors have been very kind to grant permission to use and modify
their code which somewhat mitigates my/our guilt.

>2) I did like the suggestion (in concept) of having the commons-logging
>log4j related bits live in the log4j jar.  I don't know if I have followed
>all the implications of this, but I like the idea at the moment.
>3) I also liked the idea that the commons-logging interfaces could be broken
>out from the implementations.

To be honest, I don't see any value in moving around classes from 
commons-logging
to log4j.

>4) As much as I like all the stuff that happens in commons, there are TOO
>many jars and dependencies to keep track of, IMO.  Telling new users of
>log4j all the jars that they would require to run it is going to become more
>complicated.
>5) All that said, I'm not sure any of it really solves the dependency
>problem(s).  Plus, most of log4j's configuration messages are routed through
>LogLog, not log4j itself.  Is there a way to make the digester (and related
>classes) use a LogLog version of the commons-logging interface when being
>used by log4j and do the normal stuff otherwise?

Relying on LogLog  for internal logs is not particularly elegant. It was done
because log4j appenders were not reentrant. (i.e. an appender calling
doAppend while in doAppend). This is fortunately very easy to fix by adding
a guard at the beginning of the doAppend method in AppenderSkeleton
and clearing it when leaving doAppend, along the lines of

public abstract class AppenderSkeleton implements Appender, OptionHandler {

   private boolean guard = false;

   etc ...

   public
   synchronized
   void doAppend(LoggingEvent event) {
     if(closed) {
       LogLog.error("Attempted to append to closed appender named 
["+name+"].");
       return;
     }

     if(guard) {
       return;
     }

     try {
       guard  = true;

       if(!isAsSevereAsThreshold(event.level)) {
          return;
       }

       Filter f = this.headFilter;
        etc  ....
         ....
     } finally
       guard = false;
     }
   }

Making log4j reentrant has several advantages,

1) log4j internal logs can  be controlled with the full flexibility of log4j,
2) log4j can rely on libraries that in turn rely on log4j.

I believe that the second point will become quite important in the long
run.

>-Mark

--
Ceki


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


Mime
View raw message