AW: Context deletion on redeploy[AntiVir checked]

[Thomas Strauß <T....@srs-management.de>]

Hi,

I don't see the point of your request, to be honest.

Not deleting the deployment context prior redeployment will give you all kinds of funny other problems, like jar files you incorporate with version numbers in the name (commons-logging-102.jar and commons-logging.jar). Suddenly BOTH will exist and your application may or may not run, depending on which of the two jars was loaded earlier. 

Another point is: Why not keep a configuration file OUTSIDE you context? I do not know why you did not like the global link approach. We use it and it is perfect for the many different tomcat installations we deploy to - always with the same war, by the way. 

Another idea would be to keep your properties inside the /shared/classes folder, this will also not be removed on deployment. Encrypt the password to the database (supply the user a configuration application to do so) and write the property file with the encrypted password to the shared folder.

There are numerous possibilities some tomcat specific, some interoperable between app-servers. Not removing the context prior deployment is not something I'd vote for!

Thomas

We make paper work!

SRS-Management GmbH
Berliner Ring 93

64625 Bensheim 
T        +49 6251 85 424 - 20 
F        +49 6251 85 424 - 14
Support  +49 6251 85 424 - 25

http://www.srs-management.de

HRB 25262 AG Darmstadt
Geschäftsführer: Detlev Homilius, Thomas Strauß

-----Ursprüngliche Nachricht-----
Von: kroekle [mailto:kroekle@gmail.com] 
Gesendet: Mittwoch, 5. Dezember 2007 17:54
An: users@tomcat.apache.org
Betreff: Re: Context deletion on redeploy[AntiVir checked]


I'll give my example.  I have one war file that I'm trying to deploy to
multiple environments where the only difference is the database (I have
other environment specific properties in a database table).  On top of that,
I don't know the user/password for the production environment, so I wouldn't
be able to put it in the meta-inf/context.xml if I wanted to (which I
don't).  And having an admin update the conf/Catalina/localhost/<app
name>.xml every time there is a deployment just isn't a good process and
makes a quick fix impossible.  Every "application server" I know keeps this
configuration information between deployments.

I understand that some may like the current behavior, but there are many
that do not.  I think all that anyone is asking for is to make this
configurable.  I would love to use the manager ant task with a
removeOldContext=false option, this is all I need.  Others, I think, would
like to have an option on the host removeOldContextOnUndeploy=false.  

But since this isn't going to happen overnight, can anyone offer a
suggestion to mimic this behavior now (I'm using 5.5)?  I would like to use
the ant task (which uses the manager application) to do deploys with keeping
the existing context.  Using the default context or conf/context.xml does
not work because each context has it's own realm to authenticate.

Thanks in advance.

Kurt



Christopher Schultz-2 wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark,
> 
> Mark H. Wood wrote:
>> On Wed, Sep 12, 2007 at 09:38:45AM -0400, Christopher Schultz wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> Balázs,
>>> 
>>> terenyi@freemail.hu wrote:
>>>> 4. Using Tomcat Administrator application the admin changes
>>>> environment settings defined in
>>>> conf/Catalina/localhost/warname.xml (which was extracted from the
>>>> war).
>>> Why would you make an administrator do this when you can make it
>>> part of the deployment process?
>> 
>> Why would you make the deployment process so hostile when you could 
>> let the administrator control his own machine?
> 
> According to the OP, the administrator doesn't want to do his job. IF
> it's got to be done, and the admin won't do it, then someone else has to.
> 
>>>> The only way was to put resource links to the
>>>> war/META-INF/context.xml that link to GlobalResources.
>>> This isn't true. You can put "real" resources into
>>> META-INF/context.xml. Why not just do that?
>> 
>> Perhaps because one is deploying on several different hosts and each 
>> needs different settings?
> 
> I think you're missing the point: I'm suggesting that he automatically
> configure whatever he needs on the fly.
> 
>>>> But now I have to deploy the same unmodified war many times to
>>>> the same tomcat so I have to use different settings at each
>>>> webapp.
>>> 
>>> I would highly recommend changing your deployment strategy so that
>>> you are deploying a /modified/ copy of your WAR file each time --
>>> one that has the correct settings for your environment.
>> 
>> Ewww.
>> 
>> I've seen this come up several times (and brought it up myself), and 
>> everyone is dancing around the real issue:  Tomcat seriously violates
>> the Principle of Least Surprise.
> 
> So, you think it's surprising that when you have to work around the
> standard deployment procedure (use of META-INF/context.xml) it becomes a
> real PITA? That's not surprising to me at all.. an exception case is an
> exception case.
> 
>> Programs should not muck with their own configurations on their own
>> initiative.  Sysadmins expect the settings they make to stay set.
> 
> These settings /do/ stay set, unless you re-deploy the application, at
> which point the old deployment information is stale and ought to be
> refreshed.
> 
>> If they need to override default values within a .war, their changes
>> shouldn't be blown away with every redeployment.
> 
> Except that anyone who /wants/ this behavior would have the opposite
> complaint.
> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFG6ADR9CaO5/Lv0PARAsNTAKCyh5coUNXKNTX7TgLChYsCBOmhKACeMzm+
> 58pT4H9emPzFHHbSChaxE94=
> =tvUt
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Context-deletion-on-redeploy-tf4413354.html#a14175348
Sent from the Tomcat - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org