commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: Support for JDK1.4 Logger in Commons Package
Date Thu, 04 Jul 2002 16:46:27 GMT

On Thu, 4 Jul 2002, krupa wrote:

> Date: Thu, 4 Jul 2002 09:12:20 +0100
> From: krupa <>
> Reply-To: Jakarta Commons Developers List <>
> To: 'Jakarta Commons Developers List' <>
> Subject: RE: Support for JDK1.4 Logger in Commons Package
> Hi Craig,
>   I do accept that removing Log4J from classpath makes the JDK1.4 works.
> But then why do we need to specify which factory and log to use in
> ""?  What is the use of it when there is no
> other factory than o.a.c.l.i.Log4JFactory?? Is the
> "" a bug then???.

The default LogFactory implementation does the discovery algorithm that is
documented.  As I said in a previous response, I don't know why Costin
created a custom LogFactory for Log4J -- the default factory does things
fine for me.

Of course, sometimes you *want* to be able to override LogFactory to meet
specialized requirements.  I ran into one case where the logger names
produced by Log users needed to be renamed to meet internal requirements.
This was easily done by providing a custom LogFactory that was a copy of
the standard LogFactoryImpl, but tweaked the names of the logs passed to
the constructors of the Log instances.  Pretty easy, and required no
modifications to the underlying libraries using commons-logging.

> If tweaking the o.a.c.l.i.LogFactoryImpl class makes all the Loggers
> work, there is no need for file.

Not necessarily.  For example, if you want to select the SimpleLog
implementation (writes to System.err), you still need to be able to set
the property that makes this selection, and the corresponding settings to
configure levels and such.

And nobody restricts you from writing custom Log implementations as well,
which could be served by the existing factory, and configured based on the
included properties.  There is a lot of flexibility here.

> If my application requires both the logging frameworks (Log4J and
> JDK1.4) in the classpath +how I am going to do that using the current
> c-l without factories for those Logging frameworks???

The general assumption is that a given application environment will only
use one logging implementation.  Indeed, one of the values of c-l is that
it lets you use components that rely on it (such as many of the other
commons packages) in an environment where only one log implementation is
installed, with no changes.

Here's some approaches to consider if that is not true, as appears to be
your use case:

* Abandon commons-logging and write directly to the APIs for
  Log4J and JDK 1.4 from the appropriate classes.

* Write a custom LogFactory implementation that hands out instances
  of Log4JCategoryLog or Jdk14Logger as appropriate, perhaps based
  on the requested logger name (the conventions would be determined
  by how your application defines them).

* Partition your application with class loaders, and expose Log4J
  only in the class loaders where you want application components
  to use it.  (Tomcat is an example of this -- different webapps
  can use different log factories and log implementations).

> By the way, having a separate factory helps us configuring the c-l from
> properties file rather than touching the classpath.

Yep.  And the services architecture stuff (an entry in META-INF/service)
is also a useful way to "configure" things simply by dumping a particular
JAR into your classpath.

> Regards,
> krupa.


> -----Original Message-----
> From: Craig R. McClanahan []
> Sent: 03 July 2002 19:07
> To: Jakarta Commons Developers List
> Cc: ''
> Subject: Re: Support for JDK1.4 Logger in Commons Package
> On Wed, 3 Jul 2002, krupa wrote:
> > Date: Wed, 3 Jul 2002 11:20:40 +0100
> > From: krupa <>
> > Reply-To: Jakarta Commons Developers List <>
> > To: "''" <>
> > Cc: "''" <>
> > Subject: Support for JDK1.4 Logger in Commons Package
> >
> > Hi there,
> >        I have few issues when I am using Commons Logging Package...
> >
> > No Factories provided other than for Log4J:
> >
> You don't need a special factory for this -- the default factory supports
> JDK 1.4 logging just fine (i.e. it creates instances of
> org.apache.commons.logging.impl.Jdk14Logger).  The actual JD 1.4 logging
> configuration is done in the usual way (edit "" in
> $JAVA_HOME/jre/lib).
> Thus, when I have a statement like this in my application class:
>   Log log = LogFactory.getLog("foo");
> and don't set any of the configuration variables, I get a Log4J logger
> named "foo" if Log4J is present in the class path, or a JDK 1.4 logger if
> Log4J is not present (and I'm running on 1.4, of course).
> To be honest, I have no idea why Costin implemented o.a.c.l.i.Log4jFactory
> as a separate factory implementation, instead of just tweaking the default
> o.a.c.l.i.LogFactoryImpl class.  But the standard factory supports JDK 1.4
> just fine for me.
> Craig
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>
> This message, together with any attachments, is
> confidential and is intended only for the use of
> the addressee(s) and may contain information
> which is covered by legal, professional or other
> privilege. If you are not the intended recipient,
> please destroy this E-mail and inform us.
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message