commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: [logging] log4j 1.3 support
Date Sun, 02 Oct 2005 10:33:22 GMT
On Sun, 2005-10-02 at 10:23 +0200, Joerg Hohwiller wrote:
> > I suggest you look at the current code again. Log4J12Logger has:
> > <code>
> >  // Releases of log4j1.2 >= 1.2.12 have 
> >  // Priority.TRACE available, earlier
> >  // versions do not. If TRACE is not available, then we have to map
> >  // calls to Log.trace(...) onto the DEBUG level.
> >         
> >  try {
> >    traceLevel = (Priority) Priority.class.getDeclaredField("TRACE").get(null);
> >  } catch(Exception ex) {
> >    // ok, trace not available
> >    traceLevel = Priority.DEBUG;
> >  }
> > </code>
> Jep, I have looked at the code before.
> But only the use of Priority makes this be incompatible with log4j 1.3
> This check could be changed so it is only using Level and it would still
> compile. The check would not work as easy then, but it is still possible to
> figure this out without using Priority.


In Log4J1.2, Level extends Priority and Logger extends Category.
The log method on Category only takes Priority parameters.
So any calls to the log method resolves to a method on a Category
instance that takes a Priority parameter, even when the source code is
invoking the method on a reference of type Logger and passing a
parameter of type Level. [1]

In Log4J1.3, Priority extends Level, and all the constants on the 
Priority class are actually of type Level.

The result is that no code compiled against 1.2 will run with 1.3 at
runtime. And that no code compiled against 1.3 will run with 1.2 at
runtime.

If you *can* find a way to write one logger class that (compiled against
either version) will run against both libs that would be great - but
please *test* that after compiling your code (against either library) it
works at runtime with either lib version in the classpath. I've spent
some time thinking about this and believe it can't be done.

[1]
You may find the output of
  javap -c org.apache.commons.logging.impl.Log4J12Logger
useful to see exactly what method was bound to at compile-time.

Regards,

Simon


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


Mime
View raw message