tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kroekle <kroe...@gmail.com>
Subject Re: Context deletion on redeploy
Date Wed, 05 Dec 2007 16:54:19 GMT

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


Mime
View raw message