geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: replacing tomcat classes
Date Thu, 11 May 2006 16:16:50 GMT

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?

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 earthlink.net
>>
>> "He is no fool who gives what he cannot keep, to gain what he  cannot 
>> lose."   -- Jim Elliot
> 
> 
> 
> 

-- 
Joe Bohn
joe.bohn at earthlink.net

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

Mime
View raw message