Hi Mark, Firstly, the 1.1.0 release of commons-logging will hopefully not have this problem; you don't indicate what version of commons-logging is present when this problem occurs. Could you try upgrading the JCL implementation in the tomcat path to the latest version and see what happens?
Regarding static log instances, this is really a bad idea for a number of reasons, and this is NOT specific to commons-logging but common to any logging library that allows per-webapp logging configuration. This includes log4j, slf4j and JULI. See: http://wiki.apache.org/jakarta-commons/Logging/StaticLog If beanutils is using static loggers then that really should be fixed. Actually, beanutil's liberal use of static members and methods has always struck me as being incredibly dangerous. I certainly don't want a datatype converter registered by one webapp to be visible in another! I would therefore suggest that tomcat (and all other apps) completely avoid using any static beanutils methods, and instead always access specific *instances* of the beanutils classes for beanutils functionality; that might avoid the logging issue completely. Or dump BeanUtils; there is some useful stuff in there but a lot of pretty scary stuff too.. I can't see why beanutils 1.6.1 would be "better" than 1.7.0. Your statement that because BeanUtils/ConvertUtils were static, the objects were created by the Tomcat classloader doesn't seem right to me. If the jar is bundled in a webapp, and the webapp has child-first classloading then the webapp's classloader will load those classes and hold its own copy of those statics, no? A singleton object having the same object types held as members instead of statics should have exactly the same behaviour as far as I can see, because the singleton reference is a static. There is one exception: the members will be initialised when the first singleton instance is created, not at class load time. Maybe it is that delayed member initialisation that is responsible for any behaviour difference you see? The blog entry referenced is interesting, but I can't for the moment see why it would have any effect at all. If child-first lookup is in action, and the class is available to the child classloader then that should take precedence over the parent classloader's version. And if parent-first lookup is in action, then the code shown is the default behaviour anyway isn't it? I must be missing something..will think about it some more. Mark, what specifically is your issue here? Are you a tomcat developer, or trying to write webapps to run on tomcat, or something else? Regards, Simon On Sun, 2006-08-20 at 19:36 -0400, Mark Thomas wrote: > Hi, > > The most recent Tomcat 4 release upgraded from beanutils 1.6.1 to > 1.7.0 and this introduced a conflict with commons-logging (see > http://issues.apache.org/bugzilla/show_bug.cgi?id=40252). As the > issues boils down to fun and games with containers and classloader > hierarchies, this might not be a beanutils issue at all but given the > issue became apparent after a change in beanutils this seems like the > right place to start. > > Since this discussion revolves around changes in the beanutils code, I > am posting this to the dev list. If it is felt the users list is more > appropriate, I am happy to move this thread to that list instead. > > With beanutils 1.6.1 utility classes such as BeanUtils and > ConvertUtils were static and hence the associated Log instances were > also static. All these objects were created by the Tomcat common > classloader and all was well. > > In beanutils 1.7.0 the BeanUtilsBean class was introduced as > per-context-classloader pseudo singletons. Providing commons-logging > is not present in the webapp classloader then all is well. As soon as > commons-logging is present in the webapp classloader, when the per > context classloader instance of ConvertUtilsBean creates a logger it > uses the Log class from the webapp classloader which conflicts with > that in the common classloader and "Invalid class loader hierarchy. > You have more than one version of 'org.apache.commons.logging.Log' > visible, which is not allowed." results. > > The only option for the webapp developer is not to include > commons-logging but this does make for portable webapps - not all > containers use commons-logging internally and a webapp may require > this library. For now, my short-term solution is to revert to > beanutils 1.6.1 for a TC4.1.33 release. > > Longer term, I wonder if the same sort of trick the OP for the above > bug uses in webapps (see > http://rbodkin.blogs.com/ron_bodkins_blog/2006/07/stupid_log_tric.html) > could be used in beanutils. I would be happy to work on a patch in > this direction if it was thought to be useful. However, I would value > the insight of those more familiar with the beanutils code before > starting since I don't want to waste time on a pointless exercise. > > Regards, > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
