James Carman schrieb:
> 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?
>
A file "commons-logging.properties" can be placed in the classpath to
achieve this. That is documented here:
http://commons.apache.org/logging/guide.html
A "priority" value can be encoded into the file to handle the case where
multiple files of this name are present in the classpath.Nowadays it
would be slightly nicer to use the standard "service provider"
conventions (commons-logging predates the java service provider
convention by several years) but the functionality is exactly the same.
>> 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.
>
Yes, this looks really simple at first. And it really should be, but a
combination of missing features in java (in particular, no
per-classloader user data storage), nasty java features (JCA in
particular), hot-class-reloading, and weird container features (shared
classloaders, parent-first classloading, JBoss special-casing
commons-logging, etc) makes this remarkably tricky.
> 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).
>
This info is out of date. A lot of work was put into this for the
commons-logging 1.1 release. The discovery mechanism was significantly
revised, and a new policy of *never* throwing an exception from
commons-logging was adopted.
As a result, commons-logging is now rather a complicated piece of code,
but works *much* more reliably than commons-logging 1.0.4.
>
>
>> 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.
>
What exactly do you mean by "modules"? Do you mean a separate jar per
supported library like slf4j has? Exactly the same effect can be had
just by people putting a "commons-logging.properties" file in their
classpath. I suppose we could bundle exactly the same
commons-logging.jar file 5 times, but with a different
commons-logging.properties file included, specifying the adapter to use.
What would splitting up the jar achieve that this would not?
People do not seem to have problems with commons-logging choosing the
"wrong" library to log through. Actually, I cannot remember any issues
being reported at all since 1.1 except for the bug we fixed for 1.1.1
regarding use with strict java security policies (eg applets), and the
incorrect maven2 pom.
There is the long-term issue of not having a true "api" jar to compile
against, which is why a no-op jar would be useful.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
