tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parsons Technical Services" <>
Subject Re: Reloading of apps deployed as WAR files
Date Wed, 28 Apr 2004 15:42:36 GMT
> > Unless there is something I am missing on your setups try this:
> >
> > In the manager for one of the apps click on remove. (It actually does
> > stop for you.)
> > Then go down the page to the next section where all you do is specify
> > path to your war file.
> > This will deploy the war into a folder named the same as the war file.
> We can't re-deploy this way because app deployment depends on several
> non-default things that we set in the <Context> stub, most importantly
> the context root (which cannot be just the name of the WAR file, given
> our long-established naming conventions).
> However, it does work if we use the "XML Configuration file URL"
> section to refer to the location of the <Context> stub.  But, again,
> that's more awkward and error-prone.

Okay. I missed something.  You are using the 2.3 spec method of handling
your context stub. That is where you lost me. Never messed with that myself.

> This seems an odd deficiency in Tomcat, given what we've seen in other
> products.  What could be simpler and more intuitive than a "reload"
> button for an app that works with WAR files?

Post a context stub for one of your apps. What options do you have in the

> > From the sound of things it would be worth your while to move up to TC5.
> > Then a simple remove and straight deploy from war would work fine with
> > setups as your <context> stub is part of the war.
> Moving to Tomcat 5 would be premature for us at this point, though I
> expect we will eventually.
> But it sounds like you're describing a TC-specific change to the WAR
> file format; is that the case?  That would not be an option for us
> because we need to be able to deploy on other servlet containers.  That
> would be mitigated a little (though not entirely) if the change is
> transparent to other containers.

Actually this is a new feature of the 2.4 spec and not Tomcat. And with how
you deploy, it would make things very simple and much less error prone.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message