On 14/01/2010 23:45, youngm wrote:
>> Won't help. The servlet spec requires that classes in the web
>> application take priority.
>
> The only quote I was able to find from the servlet spec was:
>
> "It is recommended also that the application class loader be
> implemented so that classes and resources packaged within the WAR are loaded
> in
> preference to classes and resources residing in container-wide library
> JARs."
>
> Seems to me that there is some wiggle room there. Besides Websphere
> actually by default deploys its web application "parent first" completely
> ignoring the above recommendation. :)
Fair enough, requires was too strong. You can change the default Tomcat
behaviour. Look for the delegate attribute on the loader.
The spec recommends not using parent first for good reasons - memory
leaks for one. Why WebSphere goes against that I have no idea.
>> Even if the solutions would work (which they won't) they seem a lot more
>> complex than
>> - unpack war
>> - replace driver jar
>> - pack war
>> - deploy through manager
>
> Here are a couple of the problems I have with the above approach:
>
> * If I'm administering an environment with 20-30 tomcat apps all of which
> require the new database driver this is a rather more difficult process for
> middleware engineers (not developers) to perform than simply (Copy this file
> into *this* directory, restart app)
That depends how much you process (and associated automation) you have.
I'd have a staging area with the original wars and the patches and a
script that generated the patched wars.
> * It would seem that the change tracking of a process like that above would
> be very difficult. It would be hard to answer questions like "What patches
> have I applied to these 20 applications in production?" If there were
> simply a folder with the patches right there then it becomes very easier to
> see how this running application's configuration differs from the
> configuration the archive was built with. This becomes more and more
> important the older an application gets and the more patches applied to it.
I can see where you are coming from with this. Unless you have only one
application per instance, the solution is going to have to be at the
web-app level and there isn't anything that springs immediately to mind.
Neither is there an easy place this could be added.
With one application per instance, changing the delegation to parent
first and placing the "patches" in lib might work. You could also enable
the shared class loader and use that. I'd be wary of memory leaks on
reload but you say you aren't reloading so that shouldn't be an issue.
I'd also be concerned about any apps that used XML parsers or anything
else where a different version might be found in a parent class loader.
>> That would update the driver for the app with zero downtime. What is the
>> issue with this approach?
>
> This may just be my organization's standard but we never hot deploy in
> production. We're too scared of permgen errors and other potential
> inconsistencies plus we have a load balancer. However, this may work for
> others so point taken.
PermGen on reload is a whole other topic :)
Getting back to your issue, with some restrictions you could probably
get something along the lines you describe working but it would be a bit
of a hack. I think a staging area with a script is a safer solution that
meets your requirements. Something like:
/staging/
/source
app1.war
app2.war
...
/patches
/app1
/WEB-INF
/lib
new.jar
/app2
...
/output
/app1.war
/app2.war
...
with a single script that iterates through source and
- expands foo.war to a tmp location
- copies /patches/foo over the top of the temp location
- creates /output/foo.war from the tmp location
You have single WARs which Tomcat work with Tomcat (and any other
container) without having to hack around
You have one place to look for patches applied to an app
The patch process is add patch files, run script, copy output WARs.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
