Comments on: The evils of commons-logging.jar and its ilk http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/?utm_source=rss&utm_medium=rss&utm_campaign=the-evils-of-commons-loggingjar-and-its-ilk If you have nothing bad to say, say nothing. Wed, 14 Dec 2011 08:51:39 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Roberto Lo Giacco http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-7834 Roberto Lo Giacco Fri, 14 Sep 2007 20:35:26 +0000 http://www.bileblog.org/?p=259#comment-7834 I don't agree with you: logging configuration depends on deployment team, not on development. What commons loggin achieve is abstracting you (the developer) from the deployment logging framework. It isn't the solution for ALL problems, but it solves many development problems. I don’t agree with you: logging configuration depends on deployment team, not on development. What commons loggin achieve is abstracting you (the developer) from the deployment logging framework. It isn’t the solution for ALL problems, but it solves many development problems.

]]> By: Bill Schneider http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6394 Bill Schneider Sat, 18 Jun 2005 08:14:50 +0000 http://www.bileblog.org/?p=259#comment-6394 no kidding. I've also suffered because of commons-logging. I recorded some potential solutions on my blog. no kidding. I’ve also suffered because of commons-logging. I recorded some potential solutions on my blog.

]]> By: Eric Bloch http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6393 Eric Bloch Fri, 27 Aug 2004 18:55:28 +0000 http://www.bileblog.org/?p=259#comment-6393 Here here. commons-logging has caused me days of time at this point. I hope to see it die soon. -Eric Here here. commons-logging has caused me days of time at this point. I hope to see it die soon.

-Eric

]]> By: Costin Manolache http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6392 Costin Manolache Sun, 14 Dec 2003 13:38:04 +0000 http://www.bileblog.org/?p=259#comment-6392 The reasons commons-logging exists are: JDK logging API is tied into JDK1.4 ( and not very good, but it's not the only half-bad/half-good API ), there are already plenty of logging implementations ( log4j, logkit, jdk logging, proprietary/custom loggers). What we want is a common API, to use across jakarta libraries and projects - and unfortunately the Sun API doesn't fit. Tomcat for example may be embedded in various app servers - like Sun reference impl, jboss, etc. Each uses it's own logging. Just like we don't want tomcat to have it's own configuration ( and in 5.0 it uses JMX - so it can use whatever the host is using instead of server.xml ) - we don't want tomcat to have it's own logging. There are also some implications on sandboxed env, where the webapps don't actually have the rights to log wherever they want, instead the admin controls all the logging. Keep in mind commons-logging is an API, and it is supposed to be a "platform" API ( like JDK1.4 logging ). It's unfortunate JDK1.4 logging didn't work and we had to do commons-logging, but it is IMO the right solution. Version management and DLL hell is a valid concern, however commons-logging has been pretty stable and backward compatible, and I don't think it creates major problems by its own. The reasons commons-logging exists are: JDK logging API is tied into JDK1.4 ( and not very good, but it’s not the only half-bad/half-good API ), there are already plenty of logging implementations ( log4j, logkit, jdk logging, proprietary/custom loggers). What we want is a common API, to use across jakarta libraries and projects – and unfortunately the Sun API doesn’t fit.

Tomcat for example may be embedded in various app servers – like Sun reference impl, jboss, etc. Each uses it’s own logging. Just like we don’t want tomcat to have it’s own configuration ( and in 5.0 it uses JMX – so it can use whatever the host is using instead of server.xml ) – we don’t want tomcat to have it’s own logging.

There are also some implications on sandboxed env, where the webapps don’t actually have the rights to log wherever they want, instead the admin controls all the logging.

Keep in mind commons-logging is an API, and it is supposed to be a “platform” API ( like JDK1.4 logging ). It’s unfortunate JDK1.4 logging didn’t
work and we had to do commons-logging, but it is IMO the right solution. Version management and DLL hell is a valid concern, however commons-logging has been pretty stable and backward compatible, and I don’t think it creates major problems by its own.

]]> By: Bruce Snyder http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6391 Bruce Snyder Wed, 17 Sep 2003 00:15:14 +0000 http://www.bileblog.org/?p=259#comment-6391 ClassWorlds (http://classworlds.codehaus.org/) is one solution to this jar hell. I'm not sure why vendors don't at least take the ClassWorlds approach of setting up separate realms or zones that each use its own ClassLoader. ClassWorlds (http://classworlds.codehaus.org/) is one solution to this jar hell. I’m not sure why vendors don’t at least take the ClassWorlds approach of setting up separate realms or zones that each use its own ClassLoader.

]]> By: Anonymous http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6390 Anonymous Wed, 13 Aug 2003 15:59:14 +0000 http://www.bileblog.org/?p=259#comment-6390 Version management is one of the most lacking aspects of Java. If Java is going to copy anything from .NET, please add some competent version management before tackling things like "foreach" syntax sugar. Every jar should have a set of formal and *required* version attributes, as well as a required set of declared jar+version dependencies. The runtime should enforce versioning requirements. This should allow multiple versions of the same jars to co-exist in a single classpath and classloader. Until this happens we will have to resort to a combination of finger-crossing/hail-Mary's and/or kludges (like re-writing the dependent package names) to have a deployment free of versioning bugs. Version management is one of the most lacking aspects of Java. If Java is going to copy anything from .NET, please add some competent version management before tackling things like “foreach” syntax sugar.

Every jar should have a set of formal and *required* version attributes, as well as a required set of declared jar+version dependencies. The runtime should enforce versioning requirements. This should allow multiple versions of the same jars to co-exist in a single classpath and classloader. Until this happens we will have to resort to a combination of finger-crossing/hail-Mary’s and/or kludges (like re-writing the dependent package names) to have a deployment free of versioning bugs.

]]> By: Anonymous http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6389 Anonymous Wed, 13 Aug 2003 09:28:17 +0000 http://www.bileblog.org/?p=259#comment-6389 IMHO you are blaming the wrong kid in this case. The logging mess in all the app servers out there is because they are not able to separate server/container and application classloaders in a way not causing conflicts with different versions of the same library. IMHO you are blaming the wrong kid in this case. The logging mess in all the app servers out there is because they are not able to separate server/container and application classloaders in a way not causing conflicts with different versions of the same library.

]]> By: Aleksander Slominski http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6388 Aleksander Slominski Mon, 11 Aug 2003 23:25:22 +0000 http://www.bileblog.org/?p=259#comment-6388 One possible solution to this is to have easy to embed into your package structure logger class. i have written such utility called MicroLogger freely available so you can tweak it to your logging needs: http://freshmeat.net/releases/131068/ Addressing comment by Daryl Oidy: i agree that requiring use JDK 1.4+ sometimes is not possible so i made sure that MicroLoggers works very well in JDK 1.2+ and has API as similar to JDK 1.4 as possible to facilitate migration. BTW: for some reasons that i am yet to grasp commons logging jar is shipped with Java source code that can confuse some IDEs: http://forum.omnicore.com/showthread.php?s=&threadid=1341 - one would anybody on earth put .java files with .class files in JAR?! or it is just me unlucky enough to get this "special" JAR? thanks, alek One possible solution to this is to have easy to embed into your package structure logger class. i have written such utility called MicroLogger freely available so you can tweak it to your logging needs: http://freshmeat.net/releases/131068/

Addressing comment by Daryl Oidy: i agree that requiring use JDK 1.4+ sometimes is not possible so i made sure that MicroLoggers works very well in JDK 1.2+ and has API as similar to JDK 1.4 as possible to facilitate migration.

BTW: for some reasons that i am yet to grasp commons logging jar is shipped with Java source code that can confuse some IDEs: http://forum.omnicore.com/showthread.php?s=&threadid=1341 – one would anybody on earth put .java files with .class files in JAR?! or it is just me unlucky enough to get this “special” JAR?

thanks,

alek

]]> By: Nick Minutello http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6387 Nick Minutello Mon, 11 Aug 2003 21:01:59 +0000 http://www.bileblog.org/?p=259#comment-6387 Crikey, a technical discussion at bileBlog?? | | I can't think of a single situation whereby I'd | want my logging output to be mixed in with the | appserver's messages. | Except when you want WebLogic's "WARNING : JDBC Connection leak" messages interleaved with your application debug logging, so you can work out where you are leaking.... -Nick Crikey, a technical discussion at bileBlog??

|
| I can’t think of a single situation whereby I’d
| want my logging output to be mixed in with the
| appserver’s messages.
|

Except when you want WebLogic’s “WARNING : JDBC Connection leak” messages interleaved with your application debug logging, so you can work out where you are leaking….

-Nick

]]> By: Cameron Purdy http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6386 Cameron Purdy Mon, 11 Aug 2003 12:01:43 +0000 http://www.bileblog.org/?p=259#comment-6386 Jive has other dependencies, such as Coherence for clustering, but they package it all in a way that is friendly for the IT pro that is installing their software. (We use Jive extensively, and we love it, and we would still love it even if they weren't a Tangosol OEM.) It takes a lot of work to make software usable, and it takes ten times that much work to make it easily installable, configurable and manageable (and in Jive's case: customizable too). Companies like Jive build their reputation on that ease, and that's why people buy their software instead of using the free open source equivalents. Jive has other dependencies, such as Coherence for clustering, but they package it all in a way that is friendly for the IT pro that is installing their software. (We use Jive extensively, and we love it, and we would still love it even if they weren’t a Tangosol OEM.)

It takes a lot of work to make software usable, and it takes ten times that much work to make it easily installable, configurable and manageable (and in Jive’s case: customizable too). Companies like Jive build their reputation on that ease, and that’s why people buy their software instead of using the free open source equivalents.

]]> By: Jason Carreira http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6385 Jason Carreira Mon, 11 Aug 2003 11:00:15 +0000 http://www.bileblog.org/?p=259#comment-6385 Craig, that's well and good in theory, but unless you move your classes to something like com.foo.mypackage.v1.MyClass you get the problem of the app server having the same class in the class path (package and class name remain the same) from different versions. Then you access the added classes in v2.0 and it breaks, because the v2.0 class it uses is not found, because the v1.0 class was found first. Craig, that’s well and good in theory, but unless you move your classes to something like com.foo.mypackage.v1.MyClass you get the problem of the app server having the same class in the class path (package and class name remain the same) from different versions. Then you access the added classes in v2.0 and it breaks, because the v2.0 class it uses is not found, because the v1.0 class was found first.

]]> By: Craig Heighton http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6384 Craig Heighton Mon, 11 Aug 2003 09:38:02 +0000 http://www.bileblog.org/?p=259#comment-6384 Why should the host application e.g. tomcat provide access to it's own logging mechanism. It should be down the people doing the deployments to manage whether they want a shared commons jar or one per web-app. the apps should not have access to the hosts apps Classloader in this way. And as for versions ALL jars should have a obvious version number and standard perfix. e.g commons-logging-1.0.jar. This allows you to search your classpath for the prefix and find out what versions are around at a glance. Dll hell comes from badly named libs and enormous search paths. NOT from shared common access code as you suggest. Why should the host application e.g. tomcat provide access to it’s own logging mechanism. It should be down the people doing the deployments to manage whether they want a shared commons jar or one per web-app. the apps should not have access to the hosts apps Classloader in this way. And as for versions ALL jars should have a obvious version number and standard perfix. e.g commons-logging-1.0.jar. This allows you to search your classpath for the prefix and find out what versions are around at a glance.

Dll hell comes from badly named libs and enormous search paths. NOT from shared common access code as you suggest.

]]> By: Daryl Oidy http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6383 Daryl Oidy Mon, 11 Aug 2003 03:22:45 +0000 http://www.bileblog.org/?p=259#comment-6383 Well, it's only in JDK 1.4, so it doesn't help you if you need to run on older JVMs. And some people would just rather stick with the logging classes they already know and love. Well, it’s only in JDK 1.4, so it doesn’t help you if you need to run on older JVMs. And some people would just rather stick with the logging classes they already know and love.

]]> By: Keith Lea http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6382 Keith Lea Mon, 11 Aug 2003 02:54:13 +0000 http://www.bileblog.org/?p=259#comment-6382 Why doesn't anyone use the JDK's logging facilities? Is it not a standard, pluggable API? (I'm really asking; I'm not being sarcastic or hostile.) Why doesn’t anyone use the JDK’s logging facilities? Is it not a standard, pluggable API? (I’m really asking; I’m not being sarcastic or hostile.)

]]> By: martin http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6381 martin Mon, 11 Aug 2003 02:33:35 +0000 http://www.bileblog.org/?p=259#comment-6381 More remedies please? More remedies please?

]]> By: lowem http://www.bileblog.org/2003/08/the-evils-of-commons-loggingjar-and-its-ilk/comment-page-1/#comment-6380 lowem Mon, 11 Aug 2003 02:00:06 +0000 http://www.bileblog.org/?p=259#comment-6380 Ah, this brings back memories of the good old weblogic.jar. Ah yes. "DLL Hell", say hello to "JAR Hell". Ah, this brings back memories of the good old weblogic.jar. Ah yes. “DLL Hell”, say hello to “JAR Hell”.

]]>