Re: [logging] JCL2.0 design - Architecture

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.

thanks,
-Mark

On 2/20/06, Boris Unckel <[email protected]> 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.
> http://marc.theaimsgroup.com/?l=log4j-dev&m=113625138015434&w=2).
>
> Maybe this is a good point to talk again about the possibility to
> combine both APIs.
> (Similiar discussion, but not completely matching:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=34185)
>
> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>