You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Carman <ja...@carmanconsulting.com> on 2008/03/03 12:25:33 UTC
[logging] Creating a 2.0 exploratory branch?
Does anyone mind if I start a 2.0 exploratory branch where we can look
into splitting JCL up into multiple modules?
James Carman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] Creating a 2.0 exploratory branch?
Posted by Torsten Curdt <tc...@apache.org>.
>>>> Does anyone mind if I start a 2.0 exploratory branch where we
>>>> can look
>>>>
>>>> into splitting JCL up into multiple modules?
Actually I have also been thinking of starting a JCL 2.0
It would be a chance to fix the bad reputation.
>>> 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 think the whole JCL problem is that it does to much. I would be all
for doing something much more simple.
That'd be e.g. - no discovery at all.
Will it in the end be similar to SLF4J - probably somewhat.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] Creating a 2.0 exploratory branch?
Posted by "simon.kitching@chello.at" <si...@chello.at>.
James Carman schrieb:
> On 3/3/08, simon.kitching@chello.at <si...@chello.at> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] Creating a 2.0 exploratory branch?
Posted by James Carman <ja...@carmanconsulting.com>.
On 3/3/08, simon.kitching@chello.at <si...@chello.at> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] Creating a 2.0 exploratory branch?
Posted by "simon.kitching@chello.at" <si...@chello.at>.
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.
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.
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.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org