Remove Commons Logging in favor of Log4j 1.3 UGLI

[blackstar]

I recently talked to Simon Kitching [skitching@apache.org] on this issue and he pointed out:

Or even better, don't deploy classes in "shared" locations. I personally believe this is not good design; applications in a container are meant to be independent.

I agree with Simon -- putting libs in shared locations isn't the best way to go.

Problems that sharing libs can cause:

1. Class loader problems - you found this one
2. Independance - what if you want to deploy two instances of your app - one with spring 1.2 and one with 2.0?
3. Maintenance - like independance (above), good luck upgrading shared libs. I've had multiple apps deployed on the same servers that *required* different lib versions.

Additional benefits of libs in war:

1. App installation and removal is simplier.
2. Purity. wars/ears stay as "everything the app needs to work", just like they should be.
3. Lib version mismatch reduced.

Costs of libs in war:

1. Disk space? At most, a couple of megs of jars repeated a couple of times on any modern machine? Not an issue.
2. Memory space? Again, not enough to matter on modern machines.

In short, the savings of sharing libs is not worth the cost.

[dvoytenko]

Hi,

Problems that sharing libs can cause:
Class loader problems - you found this one
Independance - what if you want to deploy two instances of your app - one with spring 1.2 and one with 2.0?
Maintenance - like independance (above), good luck upgrading shared libs. I've had multiple apps deployed on the same servers that *required* different lib versions

1) I don't belive Spring reports anywhere constraints of deployment in the shared locations. If this is the case, it would be fine. There's no class loader problems using it in such configurations. I don't have a problem deploying it with applications for Tomcat installation, and actually do deploy it this way. But in this case I'm not using a standard way of deploying just b/c of problems with logging.

2) While there're certainly problems with shared deployments, but the same is true with in-war deployments as well. Otherwise, managing dependencies from war deployment to shared lib deployment is not a huge problem, and probably is done for at least one library in the system.

3) Finally, the same issues related to Tomcat applications/shared hold for application server deployments, where you might be forced to deploy Spring outside of WAR files. The same problems will appear here.

In either case, JCL requirements to avoid static logs doesn't seem to be too harsh. But that would ensure appropriate work of the library in any environment.

[chunhui]

I agree with the points pointed out by Blackstar. However, I also think that we should not stick with JCL.

Any experienced developer will know you can't always get your way to do think the way you think it should be done (to share libs or to package libs in war and uncountable other issues).

For example if your manager "who happens to comes from the 80s era background where the best programmer is the one who writes the same code with the least number of instructions" thinks every Mb saved is a Mb earned. We are not talking about best practises, but in situations in which you can't do so (ligitimate or not). I wouldn't use a framework that can only work well with 100% best practises only and fails miserably otherwise.

Even the JCL's original authors condemned JCL - I'm sure you guys read about it long ago.

I've never have too much problems with it (only once earlier in my university days.), but I think if a major component of the framework is flawed fundimentally, you should change it and not force ppl to work around it.

What I like about Spring is that it gives CHOICE. So if JCL is restricting how people are configuring their apps, something should be done.

I'm sure if enough people is complaining about it, the Spring guys will change it. Its about whether there is a need and demand to get it done (since its not essentially a bug with Spring) or to put the effort in more important problems/developments at hand.

[dvoytenko]

Let me make a step back. I don't want to start the argument about "correct" deployment model for Spring or other components. I belive, if specifications allow different deployment models, someone might be using them (whether they're from 80s, 90s or 2000s). I never experienced problems with Spring framework in the shared deployment outside of JCL issues. So my point here is simply is that use of JCL seems to be the only issue that can disable this option, but there're certain steps that can be taken to preserve it (getting rid of static logs).

[click]

If this helps the argument - I did experience very nasty manifestation of JCL problems in Spring. And I wasn't happy. It wouldn't happen and I wouldn't lose half a day (or more) of my time trying to solve it if Spring was at the first place using SLF4J for instance.

Workaround I've used at the end is to throw away commons-logging.jar in favour of jcl104-over-slf4j.jar + slf4j-log4j12.jar (as log4j was used as a target logger).

[jbetancourt]

I'm having issues with logging in my new Spring MVC based web app on Tomcat 5.5.9.

I vote for removing JCL use in Spring. Perhaps Spring should eat its own dog food and have the logging implementation injected into it.

[ojs]

I migrated my applications to slf4j-log4j12 and now wanted to eliminate the dependency for jcl by using jcl104-over-slf4j (for all "legacy" applications ;-)). But unfortunately it seems there is now way to tell maven2 to ignore the dependency for jcl. If you want to do this, you have to define an jcl-exclude for any dependency in your project. Does someone has a better idea?

[lumpynose]

ojs, slf4j final has been released. Maybe it works now?

http://www.slf4j.org/

[kay]

I just discovered SLF4J and spent a bit of time reading up on it. For one thing, I much prefer their logging API - no need for "if (log.isXyzEnabled()) { ... }" statements anymore. I also quite like that it's straight-forward and only uses the logging implementation for the JAR you include in your app - I really don't see the point of JCL's dynamic discovery features.

Just read the discussion under the SLF4J 1.0 final release over on TheServerSide. Strangely, noone seems to get it? Oh well.... I also never understood what was wrong with JCL until I encountered a setup with tens of applications, and hundreds of J2EE modules, legacy code, and a custom JCL logger implementation to boot.

That said, I think that version 1.0 is a bit early to adopt such a disruptive change - especially in something the size and footprint of Spring, it might be rather irresponsible even.

[ojs]

ojs, slf4j final has been released. Maybe it works now?

http://www.slf4j.org/

No, unfortunately not. I'm not even sure if it is possible for slf4j to define such an exclude in its pom.