news [EMAIL PROTECTED] wrote on 12/27/2004 06:40:16 PM:
I think often JCL will be used as you describe, but not always.
Not always is of less concern. Matt, the PRIMARY focus of JCL is as
Ceki described. There are no if/ands/buts about it. If you choose to use
it in any other fashion, you
Charles Daniels [EMAIL PROTECTED] writes:
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
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
At 03:05 AM 12/27/2004, Charles Daniels wrote:
If I understand the JCL discovery mechanism correctly, it actually
should work just fine in the scenario you describe above. For it to
work, you would not set the org.apache.commons.logging.LogFactory system
property, because, as you pointed out,
On Mon, 27 Dec 2004 12:49:45 +0100, Ceki Gülcü [EMAIL PROTECTED] wrote:
At 03:05 AM 12/27/2004, Charles Daniels wrote:
If I understand the JCL discovery mechanism correctly, it actually
should work just fine in the scenario you describe above. For it to
work, you would not set the
Ceki Gülcü [EMAIL PROTECTED] wrote on 12/27/2004 05:49:45 AM:
At 03:05 AM 12/27/2004, Charles Daniels wrote:
If I understand the JCL discovery mechanism correctly, it actually
should work just fine in the scenario you describe above. For it to
work, you would not set the
-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
On Mon, 27 Dec 2004 12:41:56 -0600, Richard Sitze [EMAIL PROTECTED] wrote:
Ceki Gülcü [EMAIL PROTECTED] wrote on 12/27/2004 05:49:45 AM:
At 03:05 AM 12/27/2004, Charles Daniels wrote:
If I understand the JCL discovery mechanism correctly, it actually
should work just fine in the
Ceki Gülcü wrote:
At 03:05 AM 12/27/2004, Charles Daniels wrote:
If I understand the JCL discovery mechanism correctly, it actually
should work just fine in the scenario you describe above. For it to
work, you would not set the org.apache.commons.logging.LogFactory system
property, because, as
Martin Cooper [EMAIL PROTECTED] wrote on 12/27/2004 01:07:28 PM:
On Mon, 27 Dec 2004 12:41:56 -0600, Richard Sitze [EMAIL PROTECTED]
wrote:
Ceki Gülcü [EMAIL PROTECTED] wrote on 12/27/2004 05:49:45 AM:
At 03:05 AM 12/27/2004, Charles Daniels wrote:
If I understand the JCL
Matt,
JCL exists mainly for the purpose of libraries wishing to *integrate*
with the logging API chosen by the user by deferring the selection of
the logging impl to runtime. The author of library net.sf.morph
probably does *not* wish to impose any logging related property on the
end-user.
I think often JCL will be used as you describe, but not always.
For example, let's say I am developing a component that monitors
database activity and monitors usage statistics (this is a hypothetical
example). The main purpose of this component is to log messages to be
processed later by a
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
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
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
13 matches
Mail list logo
