You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2004/12/27 09:57:45 UTC
Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
"Charles Daniels" <cj...@yahoo.com> writes:
>> -----Original Message-----
>> From: Ceki G�lc� [mailto:ceki@qos.ch]
>> Sent: Sunday, December 26, 2004 11:24 AM
>> To: commons-dev@jakarta.apache.org
>> Subject: commons-logging auto-detection WAS: [logging]
>> Enterprise Common Logging... dare we say 2.0?
>>
>>
>> Simon et al.
>>
>> Log4j is slowly migrating to a model where there will be only a single
>> log4j.jar installed per Application Server. This single copy will be
>> installed under the ./common/lib or ./lib/ directories. See
>> [1, 2, 3] for
>> further details.
>>
>> Consider the case of single log4j.jar placed in ./common/lib, and two
>> web-applications called 'A' and 'B' both built on top of Struts. Also
>> assume that user of 'A' wishes to use JDK logging (j.u.l) whereas the
>> user of application 'B' wishes to use log4j. Since Struts uses JCL,
>> there is no way for user of application 'A' to direct the logs
>> generated by Struts to go to j.u.l and at the same time to have Struts
>> in application 'B' direct its logging output to log4j. (Setting the
>> org.apache.commons.logging.LogFactory system property will not help
>> because system properties are shared by all applications.)
>>
>> This simple example shows that the current JCL discovery mechanism
>> will not always work as intended.
>If I understand the JCL discovery mechanism correctly, it actually
>should work just fine in the scenario you describe above. For it to
Yep. Which once again shows, that using JCL in a component is a _good_
thing, even though Ceki will never cease to argue against it. :-)
Regards
Henning
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare
we say 2.0?
Posted by Richard Sitze <rs...@us.ibm.com>.
"Henning P. Schmiedehausen" <hp...@intermeta.de> wrote on 12/27/2004
02:57:45 AM:
> "Charles Daniels" <cj...@yahoo.com> writes:
>
> >> -----Original Message-----
> >> From: Ceki Gülcü [mailto:ceki@qos.ch]
> >> Sent: Sunday, December 26, 2004 11:24 AM
> >> To: commons-dev@jakarta.apache.org
> >> Subject: commons-logging auto-detection WAS: [logging]
> >> Enterprise Common Logging... dare we say 2.0?
> >>
> >>
> >> Simon et al.
> >>
> >> Log4j is slowly migrating to a model where there will be only a
single
> >> log4j.jar installed per Application Server. This single copy will be
> >> installed under the ./common/lib or ./lib/ directories. See
> >> [1, 2, 3] for
> >> further details.
> >>
> >> Consider the case of single log4j.jar placed in ./common/lib, and two
> >> web-applications called 'A' and 'B' both built on top of Struts. Also
> >> assume that user of 'A' wishes to use JDK logging (j.u.l) whereas the
> >> user of application 'B' wishes to use log4j. Since Struts uses JCL,
> >> there is no way for user of application 'A' to direct the logs
> >> generated by Struts to go to j.u.l and at the same time to have
Struts
> >> in application 'B' direct its logging output to log4j. (Setting the
> >> org.apache.commons.logging.LogFactory system property will not help
> >> because system properties are shared by all applications.)
> >>
> >> This simple example shows that the current JCL discovery mechanism
> >> will not always work as intended.
>
> >If I understand the JCL discovery mechanism correctly, it actually
> >should work just fine in the scenario you describe above. For it to
Not to mention within a J2EE environment, you can bind properties [such as
org.apache.commons.logging.LogFactory] to the ClassLoader. This has to be
done by the J2EE application prior to any invocation of LogFactory, but
it's do-able.
Hmm.... not so sure this works in JCL, but it does with JCDiscovery.
> Yep. Which once again shows, that using JCL in a component is a _good_
> thing, even though Ceki will never cease to argue against it. :-)
Humor aside, Ceki has taken a very reasonable view of JCL. Please, let's
not incite to humor-wars here.
>
> Regards
> Henning
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org