commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [beanutils] [logging] Webapp using commons-logging fails to start in Tomcat 4.1.x when beanutils 1.7.0 is used by Tomcat
Date Mon, 21 Aug 2006 11:26:55 GMT
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

> 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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message