On 3/3/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > James Carman schrieb: > > > Does anyone mind if I start a 2.0 exploratory branch where we can look > > into splitting JCL up into multiple modules? > > > > > I think you're biting off a really big task here. > > SLF4J has strengths, but also weaknesses. There are some things it does > better than commons-logging, but some things that it cannot do. I would > therefore be against just duplicating SLF4J and calling it the > "replacement" for commons-logging 1.1.x.
Well, I only plan on changing the discovery part. Currently, I think we just do something like this: 1. If log4j is there, use that. 2. If not, if jdk4 logging is available use that. 3. If not, then try avalon logkit, etc. I'm not saying this is the exact order (or contents for that matter), but I think that's the general idea. Of course, there's also logic that looks for system properties or properties files, etc. What I'm suggesting is to have the logic look more like this: 1. Look for a classpath resource named /META-INF/jcl-provider.xml (or properties). Use the LogFactory implementation described in that file. 2. If that's not there, just use the NoOpLogFactory implementation. 3. If there are multiple jcl-provider.xml files found, then print an error message and install the NoOpLogFactory provider as a default. Perhaps we could use proxies adapt the implementations when we have a classloader mismatch? > > There may be ways to improve commons-logging without losing the features > that do make it different from SLF4J, but as I said before, this is a > *big* task, requiring extensive knowledge of all the weird ways that > environments use classloaders. And if you want to wander into the "i18n" > area then you'll also need significant experience with multilanguage > applications, etc. I would honestly recommend organising a team of > half-a-dozen experienced developers and a wide beta-testing programme > before messing with logging... > > Of course people are always welcome to experiment; I'm just pointing out > that I would be personally very wary about releasing anything labelled > as a "replacement" or "upgrade" for the existing commons-logging, and > would need a lot of convincing before giving my personal +1 to such a > release. > You're very correct. I had no idea that it was such a big task. I assumed that JCL was somewhat simplistic. From the outside, it seems like a simple problem to solve. I've never looked into the code that much before, but I have of course been a user for quite some time. I think putting together a JCL task force would be a good thing for JCL. JCL is used by many projects, but there are a lot of newer projects that are switching to SLF4J and that's unfortunate. JCL's reputation seems to have been tarnished in the past because of its classloader troubles. The page that the SLF4J documentation refers to (http://www.qos.ch/logging/classloader.jsp) says: "This article was tested with Jakarta Commons Logging version 1.0.4. Several proposals were put forth to correct the problems in JCL's discovery code. However, there hasn't been any tangible progress so far." So, it looks like we're not willing to do anything about it. I'm willing to throw my hat in the ring to help. Are there others that would be able to volunteer some time? I may just go ahead and start a branch so that I can at least get the different modules split out (I think that's the way to go). > One smaller task that might be worthwhile is to provide a > "commons-logging-noop.jar" that just discards all logged input. That > would be particularly useful as a compile-time dependency. > Yes that will probably be in the "root" module as the default, fallback implementation. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
