geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: replacing tomcat classes
Date Thu, 11 May 2006 16:44:58 GMT

On May 11, 2006, at 9:16 AM, Joe Bohn wrote:

> Bumping up the version should work for the jar approach.  However,  
> I was still trying to figure out a way to honor the tomcat  
> recommendation of replacing just the modified classes.  Is there  
> some way to make the version independent classloaders pick up  
> individual classes rather than entire jars?

No, and I think that's a good thing.  I think the tomcat team is  
giving bad advice.

david jencks

> Joe
> David Jencks wrote:
>> On May 11, 2006, at 8:29 AM, Joe Bohn wrote:
>>> 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 think this "system patch" idea will only work in environments  
>> with  only one classloader, i.e. not geronimo.  The problem is  
>> that the  patched classes need to get into the correct  
>> classloader, "before"  the normal versions.   We'd need a patch  
>> directory for each module.   I also think any solution that relies  
>> on the order of stuff in a  classpath is inherently unstable and  
>> unreliable.
>> Basically I think this is a terrible idea and we should avoid it  
>> at  all costs.  I think instead we should use our new version   
>> independence and replace jars with patched jars with slightly  
>> higher  version numbers.  IIUC this is what you propose doing  
>> below.  This  should not require removing the standard tomcat  
>> jars: the hight  version number should be enough to get the  
>> correct version picked up.
>> thanks
>> david jencks
>>> 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?
>>> Joe
>>> 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:
>>>>> Jeff,
>>>>> 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
>>> -- 
>>> Joe Bohn
>>> joe.bohn at
>>> "He is no fool who gives what he cannot keep, to gain what he   
>>> cannot lose."   -- Jim Elliot
> -- 
> 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