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,
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 hum
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. Conseq
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 underst
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 you
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
gt; 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
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 org.apach
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
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, syst
"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-detectio
> -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 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 ./commo
13 matches
Mail list logo
