commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Tagunov <>
Subject Re: Logging packaging questions
Date Tue, 01 Jul 2003 11:00:02 GMT
Hello Nicolas!

NM> 3. people have asked for further splittage of the backend glue so they
NM> can only install the parts relevant to the backend they'll actually use
NM> (ie separate log4j, jdk 1.4, avalon... parts).

It seems 2 me I've got a solution for you :-)

1) Let's look at the way commons-logging initialization goes in
   LogFactory. (I assume this is the access point for all the

   LogFactory (yes you need to look into its source) static
   methods try to load a proper instance extending
   LogFactory abstract class (it's static getFactory() method)

   To do so they follow a specific sequence:

   1) system-wide property, org.apache.commons.logging.LogFactory
   2) META-INF/services/org.apache.commons.logging.LogFactory
      resource obtained from the context class loader
      resource obtained from the context class loader
   4) fall back to org.apache.commons.logging.impl.LogFactoryImpl

2) but the META-INF/services/... approach is _not_ really
   used by commons-logging out of the box.

   In fact only two classes extending LogFactory abstract
   class are supplied: Log4jFactory and LogFactoryImpl.

   But, LogFactoryImpl itself is a universal factory, it
   uses the


   system-wide property by itself to choose what loggers it
   will create and if does not find one it tries


   in that order.

3) So, in fact your proposition, Nicolas, wouldn't work in its
   most simplistic form. It is not enough to spread the
   existing classes over several jars to make the machinery

4) What can we do?
   _If_ we had a dedicated factory for each type of logging
   backend (which we don't, we have a universal one)
   then we could package each dedicated factory into a separate jar
   along with a proper

   But then, _if_ we really had a dedicated factory for each type
   of logging backend, we could still have all these factories
   packed into one common jar, and make each of the following jars


   contain _only_ the
   file pointing to the correct implementation (yes, I guess
   it may be a bit out of line with jar spec, but why not?)

   Naturally these jars are so simple, that you, Nicolas, can provide
   them on your own.

5) Now, we do not have a didicated factory for JDK14 logging and for
   builtin loggging. We do have one for Log4J, but everybody is probably
   using the universal factory instead, so this dedicated factory is
   probably ill tested.

   What can we do?

   One option IMO would be to subclass LogFactoryImpl (the universal
   factory) three times each time overriding its
       protected String getLogClassName()

   method. This way we shall have three deicated factories, otherwise
   identical to the universal factory and equally well tested as the
   universal factory.

   These classes are also so simplistic that you, Nicolas may provide
   them yourselves and package along with corresponding
   file into your glue jars.

   Isn't this a complete solution for you? ;-)

6) This all being said I would actually also like to configure
   commons-logging backend used by providing a proper glue
   jar and not via a system property.
   (This is probably why I have taken Nicolas's mail so close
   to heart, our likings seem to match :-)
   That's why I would also like to have these "glue" jars
   that switch my backend at my disposal independently of
   the project.

   Developers (I'm only a lowely user in _this_ list :-),
   what do you think of this wish?

- Anton

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

View raw message