Simon Kitching wrote: > 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? Tomcat currently uses commons-logging 1.0.4 but sees the same issue with 1.1.0.
> If beanutils is using static loggers then that really should be fixed. It has been fixed in 1.7.0 but this causes issues for Tomcat. > 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.. Beanutils is only used directly in a few places but where we are seeing problems is when we use commons-digester of which beanutils is a dependency. > I can't see why beanutils 1.6.1 would be "better" than 1.7.0. Generally, I am sure it isn't. However, in this particular situation 1.6.1 works and 1.7.0 does not. > Your > statement that because BeanUtils/ConvertUtils were static, the objects > were created by the Tomcat classloader doesn't seem right to me. Tomcat uses digester internally. First to configure itself (objects loaded with common classloader) and then to configure webapps (objects loaded with webapp classloader). Since in the static case the logs are created once when the static is created then all objects are created in the common classloader and there are no complaints from commons-logging. > 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? Agreed. The problem occurs when commons-logging is present in the webapp loader and in the common-loader. > 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. These are pseudo singletons (commons-beanutils terminology). They are not statics but one per classloader instances. > 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? Indeed. When commons-digester is configuring the webapp, it creates a ConvertUtilsBean for that classloader which in turn creates a log instance. If commons-logging is present in the webapp classloader and the common classloader it all goes horribly wrong. > 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. It gets around the commons-logging requirement that only one instance of commons-logging can exist in the classloader hierarchy. If the container provides it, the webapp uses it it. If it doesn't, the webapp uses its own. It essentially forces parent first classloading for commons-logging. Where a webapp requires commons-logging, it enables the webapp to be shipped without the users having to be concerned about the one commons-logging instance per classloader hierarchy issue. > Mark, what specifically is your issue here? Are you a tomcat developer, > or trying to write webapps to run on tomcat, or something else? Tomcat developer, trying to find a better fix to this bug than reverting to commons-beanutils 1.6.1 Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
