Kevan, Joe thanks for your feedback.
I had a reconsider the approach due to many circular dependencies
between org.apache.geronimo.tomcat and
org.apache.geronimo.tomcat.cluster, which prevent me to easily move
the clustering GBeans to a new project. So, I just checked-in a
better solution, which is backward compatible: I simply added a
tomcat6-no-ha that hides the Tribes classes and upon deployment of
WADI clustered applications I replace tomcat6 with tomcat6-no-ha,
which avoids the identified classloader clashes.
Thanks,
Gianny
On 03/07/2008, at 7:10 PM, Gianny Damour wrote:
Hello,
I am back from holiday; A quick scan of the mailing lists tells me
that the upgrade to WADI 2.0 is causing classloader clashes.
As identified by Jason W. and Kevan, a Tribes class is loaded by
two distinct classloaders (tomcat6 and wadi-clustering
configuration classloaders), which causes CCE upon message
delivery. After having investigated this problem, it seems to me
that the best way to fix it is to split the tomcat6 dependencies
into two configurations: tomcat6 and tomcat6-tribes. tomcat6-tribes
imports the tomcat6 configuration and the tribes dependency. The
new tomcat6 configuration is the current tomcat6 configuration
minus the tribes dependency. Such a change will break all the
configurations defining Tribes clustering GBeans. Users having such
configurations will have to redeploy them after having added the
tromcat6-tribes configuration.
I tried a backward compatible approach where the tribes dependency
was pushed up to a parent configuration. Unfortunately, this change
can only work if WADI dependencies are also imported by this new
configuration, which is a less ideal approach than the above one.
If no one objects, I intend to check-in this change over the week-end.
Thanks,
Gianny
