commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Womack" <>
Subject Re: [logging] JCL2.0 design - Architecture
Date Tue, 21 Feb 2006 16:24:03 GMT
Hi Boris,

It is a bit early for us to put any real details around log4j 2.0.  I
think it is going to be some fundamental rethinking of the api, etc. 
So, to say that log4j 2.0 will provide a native implementation of
o.a.c.l.Log, I am not sure.  Maybe other committers have an opinion. 
I suspect the issues will be similar to the issues with implementing a
native version of the slf4j api.  Also, if jcl 2.0 is moving forward
now, we might want to consider something closer to the 1.3 timeframe.

I think we are more concerned about the confusing classloader issues
in the current jcl implementation.

But, I am all for dicussing this further and seeing where it goes. 
Can we move the dicussion to a common discussion list that does not
have a lot of extraneous noise?  I don't suscribe to the jakarta
commons-dev because 99% of its contents I do not need/want to
track/filter on a daily basis.


On 2/20/06, Boris Unckel <> wrote:
> Hello,
> I know crossposting is not not wanted usually, but the case legitimates.
> The original thread on commons-dev discusses design of JCL2.0 for
> archticture and API,
> there were already some discussions about log4j 2.0 (i.E.
> Maybe this is a good point to talk again about the possibility to
> combine both APIs.
> (Similiar discussion, but not completely matching:
> log4j 2.0 could implement o.a.c.l.Log and JCL2.0 could detect this
> native implementation and
> avoid the use of an wrapper class.
> What do you think?
> Regards
> Boris
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message