Re: WAR File problem - Don't cut final version until fixe

[Costin Manolache <co...@eng.sun.com>]

Because the directory timestamp will not change if a file inside was changed.

The most common ( IMHO ) usage is for people to deploy an app and then customize
it ( change web.xml, pages, etc).

It's also something that belongs to the deployment tool - it will know for sure if
you want to update, delete or deploy. No need to spend code guessing in tomcat when
the deploy tool will have the real knowledge.



Jonathan Pierce wrote:

> Why can't we check the date on the war file when tomcat starts up, and delete
> any corresponding expanded directories if the war file is newer than it was when
> the directory was last expanded. This would not be expensive, since it only
> needs to happen once when Tomcat is restarted.
>
> The deploy tool that I use is Microsoft Frontpage, which is not designed to
> delete files automatically in the destination that are missing in the source. It
> would be better if Tomcat could clean up after itself.

I don't undestand - tomcat is just auto-deploying all war files. It doesn't have
what to
clean - after you deploy the app is available until you remove it ( by removing the
directory - until we have a deploy tool).

You can edit files in the "deployed" directory or customize ( parameters in web.xml,
like db connection urls, etc)

I think the current behavior has more advantages than guessing and expanding the
war file again.

It's something that will be resolved by a deploy tool - I would rather spend the
time writing that instead of adding strange guessing to tomcat.

Costin


>
>
> Jonathan
>
> ____________________Reply Separator____________________
> Subject:    Re: WAR File problem - Don't cut final version until fixed.
> Author: tomcat-dev@jakarta.apache.org
> Date:       4/4/00 9:30 AM
>
> It's a feature, not a bug :-)
>
> Or at least that's how it was intended to run.
>
> In a perfect world, we would have a deploy tool with 2 buttons:
> - deploy
> - remove/undeploy
>
> In tomcat, deploy means:
> - put the war file in webapps directory
>
> Undeploy means:
> - remove the war file _and_ the expanded files
>
> The expanded directory is the internal tomcat representation - if the directory
> is
> there that means the application is deployed "into" tomcat.
>
> To update you need to "un-deploy" - i.e. remove the directory. Checking for
> changes
> is too expensive and not usefull - it's the deploy tool job that has to deal
> with
> that ( in our case - you are the deploy tool, with help from "rm -rf " and "cp")
>
> Costin
>
> Jonathan Pierce wrote:
>
> > There seems to be a problem with War Files not being expanded again when the
> > server starts up if the previous expanded files exist. I am running a daily
> > snapshot from last week.
> >
> > Here is the entry from my server.xml file:
> >
> >        <Context path="" docBase="webapps/oasis" debug="0" reloadable="true">
> >         </Context>
> >
> > I have a war file named oasis.war in my webapps directory. The first time I
> run
> > tomcat and call my servlet, the war file expands into a  directory named Oasis
> > in the webapps directory. If I then stop tomcat, replace the war file, and
> start
> > it again, Tomcat serves the old previously expanded version of the servlet. I
> > need to delete the expanded directory manually to get Tomcat to reexpand the
> new
> > war file.
> >
> > Jonathan
> >
> > ____________________Reply Separator____________________
> > Subject:    The plans are to cut a final release of 3.1 this week...
> > Author: tomcat-dev@jakarta.apache.org
> > Date:       4/4/00 11:21 AM
> >
> > If anyone knows of any issues that they feel absolutely must be resolved
> > before release, please speak now or forever hold your peace!
> >
> > From what I can see, the release looks pretty good.
> >
> > - Sam Ruby
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org