Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44E8F216.5000803@apache.org>
Date: Sun, 20 Aug 2006 19:36:54 -0400
From: Mark Thomas <markt@apache.org>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: commons-dev@jakarta.apache.org
Subject: [beanutils] Webapp using commons-logging fails to start in Tomcat
 4.1.x when beanutils 1.7.0 is used by Tomcat
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org