You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Pe...@blm.gov on 2010/05/17 17:56:18 UTC
Misunderstanding deployOnStartup actions
I'm a bit confused about what the deployOnStartup setting is supposed to
do, especially when it's set to "false".
The basic question is, what is the purpose of this setting? It would appear
that if you set it to "false", then applications can only be started by
being hot-deployed, which seems rather odd but I suppose might be useful in
a development environment. By experiment I found that setting
autoDeploy=true and deployOnStartup=false, existing webapps are still
started but not until after Tomcat has already started (that is, the
applications get deployed a few seconds after Tomcat has started and is
listening, rather than during the usual startup sequence). I also found
that setting autoDeploy=false and deployOnStartup=false, no applications
will start (which is actually what I'd expect, even though it's pointless).
My guess would be that in a production setting you'd want
autoDeploy=false/deployOnStartup=true.
There's a couple of places in documentation (online, and also in the
O'Reilly book) where it says you shouldn't have hot-deployment AND
deployOnStart enabled because it can result in applications being deployed
twice - and yet the default is that autoDeploy and deployOnStartup are both
true, which seems to contradict that, and in any case I've never seen this
happen. I'm plainly misunderstanding how these settings are supposed to
work. Perhaps someone here can clarify?
Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Misunderstanding deployOnStartup actions
Posted by Pe...@blm.gov.
Notes inline...
"Caldarale, Charles R" <Ch...@unisys.com> wrote on 05/17/2010
10:11:47 AM:
> > From: Peter_Ford@blm.gov [mailto:Peter_Ford@blm.gov]
> > Subject: Misunderstanding deployOnStartup actions
> >
> >
> > I'm a bit confused about what the deployOnStartup setting is
> > supposed to do, especially when it's set to "false".
>
> It defers webapp deployment until after the container is up and
> running. Some external event is required to trigger the deployment.
That makes sense, but doesn't seem to happen - see below (1).
>
> >
> > if you set it to "false", then applications can only be
> > started by being hot-deployed
>
> No, you can use the manager or equivalent APIs to do the deployment,
> or you can configure the webapp in server.xml (not recommended).
The setup I have has all the delivered applications (manager, docs, etc.)
stripped out. There's just my application. I didn't place a context in
server.xml although I've tried it with a
conf/Catalina/localhost/[my-app-name].xml context entry, which doesn't seem
to have any effect.
>
> > I found that setting autoDeploy=true and deployOnStartup=false,
> > existing webapps are still started but not until after Tomcat
> > has already started
>
> As expected; the first request to the webapp triggers deployment.
(1) - but the app is deployed after a few seconds even when there is no
request (and if autoDeploy and deployOnStartup are both false, the app
still doesn't start on a request and I get a blank response).
>
> > I also found that setting autoDeploy=false and deployOnStartup=false,
> > no applications will start
>
> IIRC, any configured in server.xml will be started.
I haven't tried that (as I mentioned, I use an external context.xml but it
doesn't seem to have an effect).
>
> > There's a couple of places in documentation (online, and also in the
> > O'Reilly book) where it says you shouldn't have hot-deployment AND
> > deployOnStart enabled because it can result in applications being
> > deployed twice
>
> Not true; double deployment occurs when you badly configure a webapp
> located in the appBase directory, such as having its <Context>
> element in server.xml with a path attribute that does not match the
> name of the .war file or directory.
Ok, that makes sense.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY MATERIAL and is thus for use only by the intended
> recipient. If you received this in error, please contact the sender
> and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Misunderstanding deployOnStartup actions
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Peter_Ford@blm.gov [mailto:Peter_Ford@blm.gov]
> Subject: Misunderstanding deployOnStartup actions
>
>
> I'm a bit confused about what the deployOnStartup setting is
> supposed to do, especially when it's set to "false".
It defers webapp deployment until after the container is up and running. Some external event is required to trigger the deployment.
>
> if you set it to "false", then applications can only be
> started by being hot-deployed
No, you can use the manager or equivalent APIs to do the deployment, or you can configure the webapp in server.xml (not recommended).
> I found that setting autoDeploy=true and deployOnStartup=false,
> existing webapps are still started but not until after Tomcat
> has already started
As expected; the first request to the webapp triggers deployment.
> I also found that setting autoDeploy=false and deployOnStartup=false,
> no applications will start
IIRC, any configured in server.xml will be started.
> There's a couple of places in documentation (online, and also in the
> O'Reilly book) where it says you shouldn't have hot-deployment AND
> deployOnStart enabled because it can result in applications being
> deployed twice
Not true; double deployment occurs when you badly configure a webapp located in the appBase directory, such as having its <Context> element in server.xml with a path attribute that does not match the name of the .war file or directory.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Posted by Pe...@blm.gov.
Oops, forgot to say. I'm on 6.0.26. The online documentation I read is at:
http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic%20Application%20Deployment
...which is very clear about what happens with deployOnStartup="true" but
as far as I can see gives no details about what's supposed to happen when
it's set "false".
Pete
Konstantin Kolinko <kn...@gmail.com> wrote on 05/17/2010 10:05:10
AM:
> 2010/5/17 <Pe...@blm.gov>:
> > There's a couple of places in documentation (online, and also in the
> > O'Reilly book) where it says you shouldn't have hot-deployment AND
> > deployOnStart enabled because it can result in applications being
deployed
> > twice
>
> 1. For what Tomcat version?
> 2. Where online? Is it anywhere at http://tomcat.apache.org/ ?
>
> > - and yet the default is that autoDeploy and deployOnStartup are both
> > true
>
> Yes, I can confirm that they are both true by default.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/5/17 <Pe...@blm.gov>:
> There's a couple of places in documentation (online, and also in the
> O'Reilly book) where it says you shouldn't have hot-deployment AND
> deployOnStart enabled because it can result in applications being deployed
> twice
1. For what Tomcat version?
2. Where online? Is it anywhere at http://tomcat.apache.org/ ?
> - and yet the default is that autoDeploy and deployOnStartup are both
> true
Yes, I can confirm that they are both true by default.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Misunderstanding deployOnStartup actions
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
> Subject: RE: Misunderstanding deployOnStartup actions
>
> Unplugged then?
Unplugged and encased in lead, perhaps. Preferably in a dark cellar, with no stairs, in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard". (Apologies to DNA.)
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Misunderstanding deployOnStartup actions
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
Unplugged then?
With today's wake-on-lan, always on NIC connectors, I can see what you
mean.
-----Original Message-----
From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
Sent: Monday, May 17, 2010 1:14 PM
To: Tomcat Users List
Subject: RE: Misunderstanding deployOnStartup actions
> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
> Subject: RE: Misunderstanding deployOnStartup actions
>
> The only 100% secure system is one that is turned off.
Not sure even that is sufficient...
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
******************************* NOTICE *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Misunderstanding deployOnStartup actions
Posted by Martin Gainty <mg...@hotmail.com>.
give it to transocean..they need a disk to record their "BOP safety feature operational checklist procedures log" then use that disk to plug a "very large leak"
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Mon, 17 May 2010 14:43:17 -0400
> From: dckerber@verizon.net
> To: users@tomcat.apache.org
> Subject: Re: Misunderstanding deployOnStartup actions
>
> On 5/17/2010 2:19 PM, Peter_Ford@blm.gov wrote:
> > "Caldarale, Charles R"<Ch...@unisys.com> wrote on 05/17/2010
> > 12:14:21 PM:
> >
> >>> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
> >>> Subject: RE: Misunderstanding deployOnStartup actions
> >>>
> >>> The only 100% secure system is one that is turned off.
> >>
> >> Not sure even that is sufficient...
> >>
> >> - Chuck
> >
> > You could seal the hard drive in concrete then sink it in the Challenger
> > Deep... and there's still the chance that some Dr. Evil wannabe would
> > develop a sub to locate and retrieve it...
>
> I prefer wiping the drive eleven times with cryptographically-sound
> random data, then grinding the entire computer to a fine talcum-powder
> consistency, mixing it thoroughly with twenty pounds of dry powdered
> cement, then stir in the water and gravel to make concrete. When it
> starts to get thick, start stirring in the ten pounds of small
> rare-earth magnets, one at a time. Let it set, then dip it repeatedly in
> molten steel. Finally, use a high-powered electromagnet to lift and drop
> the resulting brick into the hot part of an active volcano, then push
> the planet it's on into the nearest star.
>
> I suppose an attacker *might* not be able to recover the data if you
> skipped the last step, but why take chances?
>
> :-D
>
> (I wish I had come up with this one, but can't claim it...)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
Re: Misunderstanding deployOnStartup actions
Posted by Pe...@blm.gov.
David kerber <dc...@verizon.net> wrote on 05/17/2010 12:43:17 PM:
> On 5/17/2010 2:19 PM, Peter_Ford@blm.gov wrote:
> > "Caldarale, Charles R"<Ch...@unisys.com> wrote on 05/17/2010
> > 12:14:21 PM:
> >
> >>> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
> >>> Subject: RE: Misunderstanding deployOnStartup actions
> >>>
> >>> The only 100% secure system is one that is turned off.
> >>
> >> Not sure even that is sufficient...
> >>
> >> - Chuck
> >
> > You could seal the hard drive in concrete then sink it in the
Challenger
> > Deep... and there's still the chance that some Dr. Evil wannabe would
> > develop a sub to locate and retrieve it...
>
> I prefer wiping the drive eleven times with cryptographically-sound
> random data, then grinding the entire computer to a fine talcum-powder
> consistency, mixing it thoroughly with twenty pounds of dry powdered
> cement, then stir in the water and gravel to make concrete. When it
> starts to get thick, start stirring in the ten pounds of small
> rare-earth magnets, one at a time. Let it set, then dip it repeatedly in
> molten steel. Finally, use a high-powered electromagnet to lift and drop
> the resulting brick into the hot part of an active volcano, then push
> the planet it's on into the nearest star.
>
> I suppose an attacker *might* not be able to recover the data if you
> skipped the last step, but why take chances?
>
> :-D
>
> (I wish I had come up with this one, but can't claim it...)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
...Or, I could give it to my kids and ask them *not* to destroy it...
Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Posted by David kerber <dc...@verizon.net>.
On 5/17/2010 2:19 PM, Peter_Ford@blm.gov wrote:
> "Caldarale, Charles R"<Ch...@unisys.com> wrote on 05/17/2010
> 12:14:21 PM:
>
>>> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
>>> Subject: RE: Misunderstanding deployOnStartup actions
>>>
>>> The only 100% secure system is one that is turned off.
>>
>> Not sure even that is sufficient...
>>
>> - Chuck
>
> You could seal the hard drive in concrete then sink it in the Challenger
> Deep... and there's still the chance that some Dr. Evil wannabe would
> develop a sub to locate and retrieve it...
I prefer wiping the drive eleven times with cryptographically-sound
random data, then grinding the entire computer to a fine talcum-powder
consistency, mixing it thoroughly with twenty pounds of dry powdered
cement, then stir in the water and gravel to make concrete. When it
starts to get thick, start stirring in the ten pounds of small
rare-earth magnets, one at a time. Let it set, then dip it repeatedly in
molten steel. Finally, use a high-powered electromagnet to lift and drop
the resulting brick into the hot part of an active volcano, then push
the planet it's on into the nearest star.
I suppose an attacker *might* not be able to recover the data if you
skipped the last step, but why take chances?
:-D
(I wish I had come up with this one, but can't claim it...)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Misunderstanding deployOnStartup actions
Posted by Pe...@blm.gov.
"Caldarale, Charles R" <Ch...@unisys.com> wrote on 05/17/2010
12:14:21 PM:
> > From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
> > Subject: RE: Misunderstanding deployOnStartup actions
> >
> > The only 100% secure system is one that is turned off.
>
> Not sure even that is sufficient...
>
> - Chuck
You could seal the hard drive in concrete then sink it in the Challenger
Deep... and there's still the chance that some Dr. Evil wannabe would
develop a sub to locate and retrieve it...
:)
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY MATERIAL and is thus for use only by the intended
> recipient. If you received this in error, please contact the sender
> and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Misunderstanding deployOnStartup actions
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
> Subject: RE: Misunderstanding deployOnStartup actions
>
> The only 100% secure system is one that is turned off.
Not sure even that is sufficient...
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Misunderstanding deployOnStartup actions
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
The only 100% secure system is one that is turned off.
-----Original Message-----
From: Peter_Ford@blm.gov [mailto:Peter_Ford@blm.gov]
Sent: Monday, May 17, 2010 1:09 PM
To: Tomcat Users List
Subject: Re: Misunderstanding deployOnStartup actions
Well, it's the usual thing - you can have a system that's completely
open
but gets cratered because some duffer clicked the wrong button. Or you
can
have a system that's 100% secure, but nobody can use it because it's
100%
secure. Or you can have something that's "secure enough" to protect from
accidents and any but the most determined black hat, which is really
what
I'm aiming for here.
Pete
******************************* NOTICE *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Posted by Pe...@blm.gov.
Well, it's the usual thing - you can have a system that's completely open
but gets cratered because some duffer clicked the wrong button. Or you can
have a system that's 100% secure, but nobody can use it because it's 100%
secure. Or you can have something that's "secure enough" to protect from
accidents and any but the most determined black hat, which is really what
I'm aiming for here.
Pete
Pid <pi...@pidster.com> wrote on 05/17/2010 11:47:52 AM:
> On 17/05/2010 18:14, Peter_Ford@blm.gov wrote:
> > Pid <pi...@pidster.com> wrote on 05/17/2010 10:55:06 AM:
> >
> >> On 17/05/2010 17:48, Peter_Ford@blm.gov wrote:
> >>> To clarify what I'm up to here - we have an in-house doc that
suggests
> >>> switching off autoDeploy and deployOnStartup on production systems,
and
> >>
> >> Does it explain why it makes this suggestion?
> >
> > To prevent someone accidentally (or otherwise, of course) deploying an
> > application in a production system simply by dropping in a WAR.
> >
> >>
> >>> I've been testing those recommendations on an experimental setup.
What
> > the
> >>> in-house doc forgets to say is what you've explained here (and which
> >>> answers my original question - thanks!) which is that you have to put
a
> >>> Context element into the server.xml to make it work.
> >>
> >> Which is explicity discouraged in current versions of Tomcat.
> >
> > Yes, but in a fixed production setting it makes sense. At least in that
> > setting you'd have to be able to edit server.xml, which is not
something
> > you're going to do by accident.
>
> With the right settings, you'd still need to restart the server, even if
> someone had managed to accidentally update the war files.
>
> Seems a little paranoid, but hey...
>
>
> p
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Posted by Pid <pi...@pidster.com>.
On 17/05/2010 18:14, Peter_Ford@blm.gov wrote:
> Pid <pi...@pidster.com> wrote on 05/17/2010 10:55:06 AM:
>
>> On 17/05/2010 17:48, Peter_Ford@blm.gov wrote:
>>> To clarify what I'm up to here - we have an in-house doc that suggests
>>> switching off autoDeploy and deployOnStartup on production systems, and
>>
>> Does it explain why it makes this suggestion?
>
> To prevent someone accidentally (or otherwise, of course) deploying an
> application in a production system simply by dropping in a WAR.
>
>>
>>> I've been testing those recommendations on an experimental setup. What
> the
>>> in-house doc forgets to say is what you've explained here (and which
>>> answers my original question - thanks!) which is that you have to put a
>>> Context element into the server.xml to make it work.
>>
>> Which is explicity discouraged in current versions of Tomcat.
>
> Yes, but in a fixed production setting it makes sense. At least in that
> setting you'd have to be able to edit server.xml, which is not something
> you're going to do by accident.
With the right settings, you'd still need to restart the server, even if
someone had managed to accidentally update the war files.
Seems a little paranoid, but hey...
p
> Pete
>
>>
>>
>> p
>>
>>> I need to get our doc corrected.
>>>
>>> Problem solved. Thanks all.
>>>
>>> Pete
>>>
>>> Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:38:11 AM:
>>>
>>>> On 17/05/2010 17:33, Peter_Ford@blm.gov wrote:
>>>>> Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:12:20 AM:
>>>>>> Not pointless. It limits deployed apps to *only* those defined in
>>>>>> server.xml.
>>>>>
>>>>> Ok - so if I want my app to start I have to place the context element
>>> in
>>>>> server.xml. I would have thought that an external context.xml would
>>> have
>>>>> the same effect (I thought that was the point) but I'm not seeing
> that
>>>>> happen; maybe got something wrong in that file.
>>>>
>>>> No. context.xml files are deployed via the auto-deploy process so they
>>>> need deployOnStartup or autoDeploy to be true. When I wrote "*only*
>>>> those defined in server.xml" that is exactly what I meant.
>>>>
>>>>>> That is plain wrong. autoDeployment /deployOnStartup do play a role
> in
>>>>>> double-deployment but only when your configuration is wrong to start
>>>>> with.
>>>>>
>>>>> Well, I guess I'll just have to be careful with my configuration :)
>>>>> (seriously, unless I missed it in the documentation it wasn't clear
> on
>>>>> double-deployment as a consequence of bad config.)
>>>>
>>>> Explicit definition in server.xml + autoDeploy == double deployment.
>>>> I'll add a few words to the docs to try and clarify that.
>>>>
>>>> Mark
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> [attachment "signature.asc" deleted by Peter Ford/NOC/BLM/DOI]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Misunderstanding deployOnStartup actions
Posted by Pe...@blm.gov.
Pid <pi...@pidster.com> wrote on 05/17/2010 10:55:06 AM:
> On 17/05/2010 17:48, Peter_Ford@blm.gov wrote:
> > To clarify what I'm up to here - we have an in-house doc that suggests
> > switching off autoDeploy and deployOnStartup on production systems, and
>
> Does it explain why it makes this suggestion?
To prevent someone accidentally (or otherwise, of course) deploying an
application in a production system simply by dropping in a WAR.
>
> > I've been testing those recommendations on an experimental setup. What
the
> > in-house doc forgets to say is what you've explained here (and which
> > answers my original question - thanks!) which is that you have to put a
> > Context element into the server.xml to make it work.
>
> Which is explicity discouraged in current versions of Tomcat.
Yes, but in a fixed production setting it makes sense. At least in that
setting you'd have to be able to edit server.xml, which is not something
you're going to do by accident.
Pete
>
>
> p
>
> > I need to get our doc corrected.
> >
> > Problem solved. Thanks all.
> >
> > Pete
> >
> > Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:38:11 AM:
> >
> >> On 17/05/2010 17:33, Peter_Ford@blm.gov wrote:
> >>> Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:12:20 AM:
> >>>> Not pointless. It limits deployed apps to *only* those defined in
> >>>> server.xml.
> >>>
> >>> Ok - so if I want my app to start I have to place the context element
> > in
> >>> server.xml. I would have thought that an external context.xml would
> > have
> >>> the same effect (I thought that was the point) but I'm not seeing
that
> >>> happen; maybe got something wrong in that file.
> >>
> >> No. context.xml files are deployed via the auto-deploy process so they
> >> need deployOnStartup or autoDeploy to be true. When I wrote "*only*
> >> those defined in server.xml" that is exactly what I meant.
> >>
> >>>> That is plain wrong. autoDeployment /deployOnStartup do play a role
in
> >>>> double-deployment but only when your configuration is wrong to start
> >>> with.
> >>>
> >>> Well, I guess I'll just have to be careful with my configuration :)
> >>> (seriously, unless I missed it in the documentation it wasn't clear
on
> >>> double-deployment as a consequence of bad config.)
> >>
> >> Explicit definition in server.xml + autoDeploy == double deployment.
> >> I'll add a few words to the docs to try and clarify that.
> >>
> >> Mark
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
> [attachment "signature.asc" deleted by Peter Ford/NOC/BLM/DOI]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Posted by Pid <pi...@pidster.com>.
On 17/05/2010 17:48, Peter_Ford@blm.gov wrote:
> To clarify what I'm up to here - we have an in-house doc that suggests
> switching off autoDeploy and deployOnStartup on production systems, and
Does it explain why it makes this suggestion?
> I've been testing those recommendations on an experimental setup. What the
> in-house doc forgets to say is what you've explained here (and which
> answers my original question - thanks!) which is that you have to put a
> Context element into the server.xml to make it work.
Which is explicity discouraged in current versions of Tomcat.
p
> I need to get our doc corrected.
>
> Problem solved. Thanks all.
>
> Pete
>
> Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:38:11 AM:
>
>> On 17/05/2010 17:33, Peter_Ford@blm.gov wrote:
>>> Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:12:20 AM:
>>>> Not pointless. It limits deployed apps to *only* those defined in
>>>> server.xml.
>>>
>>> Ok - so if I want my app to start I have to place the context element
> in
>>> server.xml. I would have thought that an external context.xml would
> have
>>> the same effect (I thought that was the point) but I'm not seeing that
>>> happen; maybe got something wrong in that file.
>>
>> No. context.xml files are deployed via the auto-deploy process so they
>> need deployOnStartup or autoDeploy to be true. When I wrote "*only*
>> those defined in server.xml" that is exactly what I meant.
>>
>>>> That is plain wrong. autoDeployment /deployOnStartup do play a role in
>>>> double-deployment but only when your configuration is wrong to start
>>> with.
>>>
>>> Well, I guess I'll just have to be careful with my configuration :)
>>> (seriously, unless I missed it in the documentation it wasn't clear on
>>> double-deployment as a consequence of bad config.)
>>
>> Explicit definition in server.xml + autoDeploy == double deployment.
>> I'll add a few words to the docs to try and clarify that.
>>
>> Mark
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Misunderstanding deployOnStartup actions
Posted by Pe...@blm.gov.
To clarify what I'm up to here - we have an in-house doc that suggests
switching off autoDeploy and deployOnStartup on production systems, and
I've been testing those recommendations on an experimental setup. What the
in-house doc forgets to say is what you've explained here (and which
answers my original question - thanks!) which is that you have to put a
Context element into the server.xml to make it work. I need to get our doc
corrected.
Problem solved. Thanks all.
Pete
Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:38:11 AM:
> On 17/05/2010 17:33, Peter_Ford@blm.gov wrote:
> > Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:12:20 AM:
> >> Not pointless. It limits deployed apps to *only* those defined in
> >> server.xml.
> >
> > Ok - so if I want my app to start I have to place the context element
in
> > server.xml. I would have thought that an external context.xml would
have
> > the same effect (I thought that was the point) but I'm not seeing that
> > happen; maybe got something wrong in that file.
>
> No. context.xml files are deployed via the auto-deploy process so they
> need deployOnStartup or autoDeploy to be true. When I wrote "*only*
> those defined in server.xml" that is exactly what I meant.
>
> >> That is plain wrong. autoDeployment /deployOnStartup do play a role in
> >> double-deployment but only when your configuration is wrong to start
> > with.
> >
> > Well, I guess I'll just have to be careful with my configuration :)
> > (seriously, unless I missed it in the documentation it wasn't clear on
> > double-deployment as a consequence of bad config.)
>
> Explicit definition in server.xml + autoDeploy == double deployment.
> I'll add a few words to the docs to try and clarify that.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Posted by Mark Thomas <ma...@apache.org>.
On 17/05/2010 17:33, Peter_Ford@blm.gov wrote:
> Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:12:20 AM:
>> Not pointless. It limits deployed apps to *only* those defined in
>> server.xml.
>
> Ok - so if I want my app to start I have to place the context element in
> server.xml. I would have thought that an external context.xml would have
> the same effect (I thought that was the point) but I'm not seeing that
> happen; maybe got something wrong in that file.
No. context.xml files are deployed via the auto-deploy process so they
need deployOnStartup or autoDeploy to be true. When I wrote "*only*
those defined in server.xml" that is exactly what I meant.
>> That is plain wrong. autoDeployment /deployOnStartup do play a role in
>> double-deployment but only when your configuration is wrong to start
> with.
>
> Well, I guess I'll just have to be careful with my configuration :)
> (seriously, unless I missed it in the documentation it wasn't clear on
> double-deployment as a consequence of bad config.)
Explicit definition in server.xml + autoDeploy == double deployment.
I'll add a few words to the docs to try and clarify that.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Posted by Pe...@blm.gov.
Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:12:20 AM:
> On 17/05/2010 16:56, Peter_Ford@blm.gov wrote:
> >
> > I'm a bit confused about what the deployOnStartup setting is supposed
to
> > do, especially when it's set to "false".
>
> It controls if apps are deployed when Tomcat starts.
>
> > The basic question is, what is the purpose of this setting? It would
appear
> > that if you set it to "false", then applications can only be started by
> > being hot-deployed, which seems rather odd but I suppose might be
useful in
> > a development environment. By experiment I found that setting
> > autoDeploy=true and deployOnStartup=false, existing webapps are still
> > started but not until after Tomcat has already started (that is, the
> > applications get deployed a few seconds after Tomcat has started and is
> > listening, rather than during the usual startup sequence).
>
> That will be hot-deployment kicking in ~15 secs after Tomat starts.
...which confirms what I was thinking.
>
> > I also found
> > that setting autoDeploy=false and deployOnStartup=false, no
applications
> > will start (which is actually what I'd expect, even though it's
pointless).
>
> Not pointless. It limits deployed apps to *only* those defined in
> server.xml.
Ok - so if I want my app to start I have to place the context element in
server.xml. I would have thought that an external context.xml would have
the same effect (I thought that was the point) but I'm not seeing that
happen; maybe got something wrong in that file.
>
> > My guess would be that in a production setting you'd want
> > autoDeploy=false/deployOnStartup=true.
>
> That is usually what I see.
>
> > There's a couple of places in documentation (online, and also in the
> > O'Reilly book) where it says you shouldn't have hot-deployment AND
> > deployOnStart enabled because it can result in applications being
deployed
> > twice - and yet the default is that autoDeploy and deployOnStartup are
both
> > true, which seems to contradict that, and in any case I've never seen
this
> > happen. I'm plainly misunderstanding how these settings are supposed to
> > work. Perhaps someone here can clarify?
>
> That is plain wrong. autoDeployment /deployOnStartup do play a role in
> double-deployment but only when your configuration is wrong to start
with.
Well, I guess I'll just have to be careful with my configuration :)
(seriously, unless I missed it in the documentation it wasn't clear on
double-deployment as a consequence of bad config.)
Pete
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Posted by Mark Thomas <ma...@apache.org>.
On 17/05/2010 16:56, Peter_Ford@blm.gov wrote:
>
> I'm a bit confused about what the deployOnStartup setting is supposed to
> do, especially when it's set to "false".
It controls if apps are deployed when Tomcat starts.
> The basic question is, what is the purpose of this setting? It would appear
> that if you set it to "false", then applications can only be started by
> being hot-deployed, which seems rather odd but I suppose might be useful in
> a development environment. By experiment I found that setting
> autoDeploy=true and deployOnStartup=false, existing webapps are still
> started but not until after Tomcat has already started (that is, the
> applications get deployed a few seconds after Tomcat has started and is
> listening, rather than during the usual startup sequence).
That will be hot-deployment kicking in ~15 secs after Tomat starts.
> I also found
> that setting autoDeploy=false and deployOnStartup=false, no applications
> will start (which is actually what I'd expect, even though it's pointless).
Not pointless. It limits deployed apps to *only* those defined in
server.xml.
> My guess would be that in a production setting you'd want
> autoDeploy=false/deployOnStartup=true.
That is usually what I see.
> There's a couple of places in documentation (online, and also in the
> O'Reilly book) where it says you shouldn't have hot-deployment AND
> deployOnStart enabled because it can result in applications being deployed
> twice - and yet the default is that autoDeploy and deployOnStartup are both
> true, which seems to contradict that, and in any case I've never seen this
> happen. I'm plainly misunderstanding how these settings are supposed to
> work. Perhaps someone here can clarify?
That is plain wrong. autoDeployment /deployOnStartup do play a role in
double-deployment but only when your configuration is wrong to start with.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Misunderstanding deployOnStartup actions
Posted by Pid <pi...@pidster.com>.
On 17/05/2010 16:56, Peter_Ford@blm.gov wrote:
>
> I'm a bit confused about what the deployOnStartup setting is supposed to
> do, especially when it's set to "false".
>
> The basic question is, what is the purpose of this setting? It would appear
> that if you set it to "false", then applications can only be started by
> being hot-deployed, which seems rather odd but I suppose might be useful in
> a development environment. By experiment I found that setting
> autoDeploy=true and deployOnStartup=false, existing webapps are still
> started but not until after Tomcat has already started (that is, the
> applications get deployed a few seconds after Tomcat has started and is
> listening, rather than during the usual startup sequence). I also found
> that setting autoDeploy=false and deployOnStartup=false, no applications
> will start (which is actually what I'd expect, even though it's pointless).
There are two attributes, both have obvious reasons for existing and
each has a binary value.
There doesn't need to be a specific use case for all 4 conditions.
p
> My guess would be that in a production setting you'd want
> autoDeploy=false/deployOnStartup=true.
>
> There's a couple of places in documentation (online, and also in the
> O'Reilly book) where it says you shouldn't have hot-deployment AND
> deployOnStart enabled because it can result in applications being deployed
> twice - and yet the default is that autoDeploy and deployOnStartup are both
> true, which seems to contradict that, and in any case I've never seen this
> happen. I'm plainly misunderstanding how these settings are supposed to
> work. Perhaps someone here can clarify?