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.
I agree that it would be very unwieldy. For some folks providing support for Geronimo it might be
nice for the classloaders to look in an aside dir (./patches) for a jar with the artifact name with
a -pyyyymmddss suffix so patches can be applied. The ss allows for the sequencing to be addressed.
This would make it easier to provide one hit patches that can get rolled up into the released jar
you describe below and the user would not have to wait for a release to come out which could be a
few months.
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
