Hi All, A week or so ago I was prompted by new activity on the logging topic to review what is currently sitting in SVN. I think it's actually quite good, and perhaps we could try to push for a release.
The issues I'm aware of are: * Do we include the ServletContextListener stuff or not? And if we do, do we put it in an "optional" jar or in the main jar? Personally, I would like to include it, and put it in the main jar. It does no harm being there, as no logging classes reference it. It only gets used if someone explicitly references it from a web.xml file. There have been objections about adding "dependencies", but JCL is a project that already has heaps of compile-time dependencies that aren't actually runtime dependencies, eg LogKit is a compile-time dependency too, but isn't needed to run. * Do we include the WeakHashtable stuff or not? And if so, do we put it in an "optional" jar or in the main jar. On the positive side, it will fix memory leaks for many people. And on JDKs that don't support weak references JCL politely falls back to a standard hashtable. On the negative side it isn't a 100% fix; it won't work if the LogFactoryImpl is loaded from a parent loader but the log adapter class is loaded from the webapp. This isn't a common situation, but a partial fix can be confusing. And the ServletContextListener should be a 100% fix. The other concern is that it is a lot of new - and quite tricky - code. I can't make up my mind on this. I'm tempted to put it in an optional jar. However if we put it in the main jar, then (a) we don't need to document its use so much, and (b) we could do away with the optional jar completely which would be nice. * There's a proposal to add a system property to disable all TCCL use. It's worth considering. * There's a proposal to add "get logger name" functionality. * We still don't handle "cross-application" calls. Apparently by using JCA or similar one component can get a reference to an object in another container and make a call to it. In that case, there is absolutely no way the existing code can load a log adapter class from the contextClassLoader and cast it to a Log implementation. Currently, we walk the classloader ancestry chain looking for which loader is a child of which, and find they aren't related so panic. Perhaps we could just fall back to using diagnostic logging to output a message, then assign a NoOp logger? * How do we handle Log4J 1.2->1.3 stuff? Some people have offered to investigate whether a single class can handle both versions. If that doesn't work out, then what? Currently, SVN has *removed* the Log4JLogger class, and added Log4J12Logger/Log4J13Logger. My reasons are documented in a recent email to this list (or was it the user list?). It's obviously up for debate though. And do we want to offer 1.3 support, given that 1.3 is still alpha? I would prefer not to; better to provide a minor release after log4j 1.3 is released than provide ahead-of-time support and get it wrong. Actually, for the current release we could provide a Log4JLogger class with TRACE support, and worry about splitting into log4j1.2/1.3 when the new version comes along. I would still like to see the version-checking stuff in the Log4J12Logger class kept, though. Anything else?? Note that I'm still very short of time at the moment. I'd really like to see a new JCL release, but can't promise to contribute much towards it at the moment. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
