geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: replacing tomcat classes
Date Thu, 11 May 2006 15:29:00 GMT

Thanks for the quick response Jeff.

I like the idea of a "system patch" location in the classpath where we 
can pick up patches for anything we might include in a geronimo  assembly.

I too was confused by the tomcat recommendation but it does seem that 
they have a strategy for addressing necessary changes with minimal 
interference in tomcat.  I have also noticed some things that make me 
wonder if my local tomcat build of 5.5.15 really does match the official 
5.5.15 build.  For example, the only source for 5.5.15 that I could find 
was a zip file rather than a svn branch or tag.  I am not able to build 
from the unpacked zip without making a change to move the contents of 
jasper/jasper2 into the jasper directory itself.  And the version that 
is displayed when I hit tomcat with my rebuilt image is 5.5 rather than 
5.5.15 as with the official image.

Until we figure out the correct approach for Geronimo I'm thinking of 
using a compromise solution.   The changes I need in tomcat result in 4 
of the 13 tomcat jars getting rebuilt.   Rather than replacing all of 
the tomcat jars with my local build I have verified that replacing just 
the 4 changed jars appears to work fine.  I'm hoping this hybrid 
solution keeps most of the official tomcat image and our local changes. 
   I haven't noticed any problems.   Assuming the source is mostly 
identical (apart from our changes) does anybody know of a reason that I 
should definitely not take this approach?


Jeff Genender wrote:
> Ultimately, we probably would need to somehow build a "patch" directory
> or lib directory where we can ensure the URLClassLoader picks that up
> before all other classes.  I think this is probably a good idea to have
> as well, so that we could release "service paks" or patches.  I would be
> interested in others' thoughts on this, but I think this would be a nice
> feature to have.
> Right now I think your only choices are to either hard set a classpath
> to be sure the patches get picked up first or build a hacked Tomcat
> version, or rebuild Tomcat.  Dain or David Jencks may be able to verify
> if the classpath solution would work or not as I have not dug into the
> new G classloaders to know if this would even be possible.
> The best solution right now may be to just build TC. I am a little
> confused as to why the TC guys say not to build the Tomcat from source
> (after its hacked).  It seems like just an ant build script, so I don't
> understand why this is being discouraged.  This way you can replace the
> Tomcat jars in the repo and you are good to go.
> Jeff
> Joe Bohn wrote:
>>I am working with a user that is moving some applications from tomcat to
>>geronimo.   Due to some problems they have had to modify tomcat source.
>> I was chatting with jasonb on the tomcat irc channel and he recommended
>>that we only build the classes rather than rebuilding all of tomcat.  He
>>discouraged rebuilding all of tomcat because there are many permutations
>>that can result in different build images and we should run with as much
>>of the official tomcat build as possible to avoid problems.  He also
>>indicated that Tomcat's directory structure provides a place to put
>>these "patch classes" in CATALINA_HOME/server/classes .
>>Is there a similar place that we can put classes when tomcat is running
>>under geronimo to have them picked up?  Adding the tomcat classes to our
>>new sharedlib doesn't seem to be the right place because it would
>>require a dependency from the tomcat config on sharelib.  The net result
>>would be that all tomcat apps would potentially pick up user classes
>>added in sharedlib even if the user only intended these classes for some
>>subset of the apps.

Joe Bohn
joe.bohn at

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

View raw message