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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
