[slf4j-user] New LogFactory stuff to select adapter

[Ceki Gülcü]

Hello Simon,

At 14:29 5/25/2005, Simon Kitching wrote:
>Hi Ceki,
>
>I see code has recently been added to LogFactory to use system
>properties to determine the adapter class to use. If no such property is
>set, then default to the statically bound class.
>
>Unfortunately, I don't see the point of this.
>
>System properties are global across all components in a container (eg
>webapps). There is no ability to set different system properties per
>container. So this would force the same adapter to be used across all
>components, yes?

Yes,  the  same  adapter  will  be used  across  all  components  (e.g
webapps). In other words, a  particular web-app would lose the ability
specify a  different adapter. However, this does  not necessarily mean
that the same logging implementation  will be used across all webapps.
Nothing   prevents   the   adapter   from  using   different   logging
implementation depending  on instructions from the  webapp itself. For
example, assume the adapter preforms  a JNDI lookup to decide upon the
logger  implementation to  return.  The  adapter can  read environment
variables setup by the webapp in its web.xml file. Given that the J2EE
specification guarantees  that environment variables  are distinct for
each webapp, you  get separation of logging per  webapp. Log4j 1.2 and
later use this technique  to provide separate *log4j* environments per
web-application.  The  recent changes in  SLF4J pave the way  for same
technique  to  be  employed  to  solve the  more  general  problem  of
returning different implementation per webapp.

 From what I hear, the JNDI approach is already used in production
systems with success. (We use it in all our systems in production.)

>JCL tries to solve this issue by avoiding system properties and instead
>looking for a file "commons-logging.properties" in the context classpath
>(or META-INF/services/org.apache.commons.logging.LogFactory) and using
>an entry from that to specify the adapter class to use. This
>does provide the per-component configurability that is really needed.
>Unfortunately that approach carries a fair bit of complexity with it:
>   * need to access context classloader
>   * accessing context classloader can trigger security exceptions, so
>     need to do it within an AccessController
>   * need to read the file found and extract a key entry
>   * need to handle case where child classloader is parent-first and
>     the parent has a config file with the same name. JCL1.0.4 doesn't
>     actually handle this correctly, but the upcoming release should.
>
>I don't know what the "right" solution is, but I don't see system
>properties as being appropriate for selecting the adapter class in a
>container that may have multiple components.

I would like to belive that the right solution is to build upon the
APIs that already exist in the J2EE spec rather than inventing our
own.


>Regards,
>
>Simon

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/