geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: replacing tomcat classes
Date Thu, 11 May 2006 15:00:54 GMT
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.


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

View raw message