commons-logging vs log4j directly

[Sutra Zhou]

Hi,
Why not use commons-logging( http://commons.apache.org/logging/ ) instead of log4j.

As a common developing library, if using log4j, it will force our user to use log4j.

Sutra

[Johan Karlberg]

SLF4J has adapters that will adapt the log4j calls to whichever other SLF4J logging provider you prefer. including commons-logging.

On the other hand, I agree that a switch to one of the abstract loggers (although my preference is apparently slf4j over commons-logging), would be beneficial, making choice of logger a choice for the application developer, not the library developer.

Johan

[David Fuelling]

The idea of having a generic logger so that the developer can use whichever logging facility they prefer is attractive.  **However**, my experience with using Log4j and commons-logging (together) is that there are then two config files that need to be manipulated/adjusted to get the logging right.  Maybe that's not the "correct" way to do it (I wasn't the one who designed that particular project), but it sure was a pain, especially when I wasn't aware that two logging mechanisms were being used at the same time.

Is there some shortcoming in log4j that would make a developer prefer a different logging mechanism?  Until somebody can put forward some good reason why, I would vote for just using log4j for ease of use and simplicity.

(of course, I *am* open to hearing those alternative arguments).

david

[Johan Karlberg]

I don't believe there is a deficiency in log4j, per se. The problem exists in the fact that openid4java is a small portion of most projects, and having policy like choice of logger decided for you by your dependencies, rather than being able to make the choice yourself from your projects perspective, is not very pleasant. It's my personal oppinion that libraries should depend on an abstract logging API, which in effect means slf4j-api or commons-logging, and leave the actuall logger to the implementing project. (example applications and similar within openid4java should of course still depend on a concrete implementation, which can well be log4j if that is what is preferred).

Johan

[Johnny Bufu]

On 9-Sep-07, at 4:13 PM, Johan Karlberg wrote:
> libraries should depend
> on an abstract logging API, which in effect means slf4j-api or
> commons-logging, and leave the actuall logger to the implementing
> project.

We have chosen log4j initially for simplicity and for being one of
the most popular loggers. I also think it's a good thing to give
developers who openid-enable their sites the option of using their
choice of loggers.

The questions then would be:

- which one should we use? commons-logging / slf4j / others?

- what's required to make the switch over to commons-logging
- can the configuration be kept simple?

- how will this change affect current deployments when they need to
upgrade?

Johnny

[Sutra Zhou]

2007/9/10, Johnny Bufu <joh...@sxip.com>:

On 9-Sep-07, at 4:13 PM, Johan Karlberg wrote:
> libraries should depend
> on an abstract logging API, which in effect means slf4j-api or
> commons-logging, and leave the actuall logger to the implementing
> project.

We have chosen log4j initially for simplicity and for being one of
the most popular loggers. I also think it's a good thing to give
developers who openid-enable their sites the option of using their
choice of loggers.

The questions then would be:

- which one should we use? commons-logging / slf4j / others?

commons-logging is most popular, many many projects are using it, such as springframework, hibernate  .I know little about slf4j.

See spring: http://mirrors.redv.com/maven2/org/springframework/spring-full/1.2.8/spring-full-1.2.8.pom

    <dependency>
      <groupId>commons-logging</groupId>
      <artifactId>commons-logging</artifactId>    <--------------Requires
    </dependency>

    <dependency>

      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
      <optional>true</optional>   <-----------------------optional

    </dependency>

hibernate: http://mirrors.redv.com/maven2/org/hibernate/hibernate/3.2.5.ga/hibernate-3.2.5.ga.pom

		<dependency>
			<groupId>commons-logging</groupId>
			<artifactId>commons-logging</artifactId>
			<version>1.0.4</version>
		</dependency>

- what's required to make the switch over to commons-logging
        - can the configuration be kept simple?

Add commons-logging  dependency as requires, add log4j dependency as optional.
Change the logger definition in the class from log4j to commons-logging.

- how will this change affect current deployments when they need to
upgrade?

Nothing to do except adding commons-logging dependency.

Johnny

[Johan Karlberg]

I agree that commons-logging is the most used of the two. although I suspect that is mostly by virtue of having been around longer.

My experience with commons-logging is limited, and mostly consists of being annoyed at broken poms. (the 1.1 poms  pull in every log framework it knows about as a transitive dependency, unless you explicit excludes ones you don't want. this should be fixed in the next release, which has been pending for four months). I have in the past been advised that version prior to 1.1 suffer from some obscure class loader problem that I have never encountered myself in real life, see http://www.qos.ch/logging/classloader.jsp for more information).

you mention hibernate as an example, so I direct you to http://opensource.atlassian.com/projects/hibernate/browse/HHH-2696 which indicates that hibernate is switching to slf4j in version 3.3, and that the change is in their current trunk.
 
Spring has as far as I can tell said that they will not change tom JCL to another log abstraction until some arbitrary set of other projects have already done so. (Spring OSGi however uses slf4j, but I'm unsure of their rationale for this)

including slf4j in your project would be about the same amount of work as for commons-logging, except that you explicitly specify the log adapter to use, to avoid doing the class loader tricks that supposedly got JCL into trouble.

           <dependency>
               <groupId>org.slf4j</groupId>
               <artifactId>slf4j-api</artifactId>
               <version>1.4.2</version>
           </dependency>
           <dependency>
               <groupId>org.slf4j</groupId>
               <artifactId>slf4j-log4j12</artifactId>
               <version>1.4.2</version>
           </dependency>

The slf4j-api artifact is the abstraction API that library portions of openid4java would depend on. The slf4j-log4j12 is the log4j 1.2.x adapter that is needed to route logging to the log4j implementation (the slf4j-log4j12 artifact has a transitive dependency on log4j itself, of course), and should be depended upon by sample consumers for example, which need a concrete logger. the existing log4j configuration file will be used and no slf4j specific configuration file is needed.

In addition, I use the following artifact tin my project to map users of JCL to slf4j. This is useful if you have dependencies that don't agree with your choice of logging, and could probably be used by this project for the migration period, although I would advice to do the log migration, which ever api is chosen, in one go and deal with even more abstractions. it's typically not a great deal of work to migrate logging.

            <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>jcl104-over-slf4j</artifactId>
                <version>1.4.2</version>
            </dependency>

Johan

[Johan Karlberg]

Not sure if attachments work here, but I'll give it a shot. A migration, to either framework should not be much more difficult than the attached patch. there is some cleanup needed in the poms for it to be a proper patch, but with trunk, and especially the maven bits thereof in such flux as it appears to be in right now, it didn't seem worthwhile to fix properly. The patch is not tested except that it compiles, so handle with care.

This patch only touches openid4java itself. It's dependencies may bring in commons-logging or an explicit logger on it's own (if anything brings in slf4j, it should be overridden by our explicit includes anyway), and a separate decision will be needed about that to do with those. either bridge them to slf4j or leave them be.

Johan

[Johnny Bufu]

On 10-Sep-07, at 2:20 AM, Johan Karlberg wrote:

> I agree that commons-logging is the most used of the two. although
> I suspect
> that is mostly by virtue of having been around longer.

I'd say then that we should stay with commons-logging. If slf4j gains
popularity we can always switch over, with probably the same search/
replace effort as we're about to do now.

So, Sutra :) since you started this thread, would you like to do it?

Also: I'm still not clear if commons-logging picks up automatically
and enables a log4j.properties file from the classpath, or something
else needs to be configured as well. Does anyone have this answer
already?

The former would definitely be preferred, but we should document the
logging configuration regardless.

Thanks,
Johnny

[Sutra Zhou]

commons-logging will automatically find the log4j's class.
No additional configuration files.

OK, I'll handle this: change from log4j to commons-logging.

2007/9/11, Johnny Bufu < joh...@sxip.com>:

[David Bernard]

Hi, I'm new to openID (trying to create an adapter for Wicket).

In my experience, slf4j is a better choice for libraries because :
* it doesn't force users to follow the same backend logging as the lib
or to manage several configuration (simple, jdk, log4j, logback,...)
* the api is better than the one of commons-logging (it's not perfect,
but better)
if (logger.isDebugEnabled()) { logger.debug("toto ... "+ bar)}
become
logger.debug("toto {} ", bar);
* I lost time with the classloader issue, and conflict version of
commons-logging (when J2EE container already provide "out-dated"
version)

Several lib and framework have already switch to slf4j (jetty,
wicket... I don't know about spring or hibernate).

Just a fix about previous pom.xml sample :

<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.4.2</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.4.2</version>
</dependency>

for a lib the dependency to slf4j-log4j12 must be remove, or set to
scope "test" or "provided" (like for servlet) because the final choice
is done by user.

my 2 cents (may be too later)