I'm wanting to move away from log4j as a public api. If we continue to
use it we should obfuscate it as a server implementation detail. With
jboss5 we should be able to support per deployment context logging
configuration that ties into the server logging, or is isolated, for
whatever logging framework make sense.
In terms of the next jboss-4.0.x release, we can see if the log4j-1.2.13
release causes any problems before considering whether it should be
updated.
-----Original Message-----
From: Adrian Brock
Sent: Tuesday, July 25, 2006 8:25 AM
To:
JBoss.org development list
Cc: Scott M Stark
Subject: Re: [JBoss-dev] Log4j ugrade?
I'm against upgrading log4j if it means the api/spi changes.
The bug report you linked is just one example of the type of
problem this causes, not just for us but for end users as well.
There has to be both forwards and backwards compatibility.
On Tue, 2006-07-25 at 10:11 -0500, Dimitris Andreadis wrote:
> Should we consider upgrading log4j? Any obvious reasons not
to upgrade?
>
> We are at <componentref name="apache-log4j"
version="1.2.8"/>
>
> And the latest is:
>
> log4j version 1.2.13
>
> Log4j version 1.2.13 contains several bug fixes related to
the TRACE
> level introduced in version 1.2.12 and a fix in the ConsoleAppender
> for a bug that affected JBoss.
>
> The next major release of log4j will be version 1.3. It
will contain
> many new features and changes, and if you have written
custom code, it
> may need to be modified to work with it. Please see the document
> entitled preparing for log4j 1.3 for a more detailed discussion.
>
> See also
>
http://jira.jboss.com/jira/browse/JBAS-3316
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxx