On 3 March 2013 19:44, Mark Thomas <ma...@apache.org> wrote:
> On 03/03/2013 19:25, James Green wrote:
> > I am clearly inferring too much. An explicit statement would certainly
> help
> > reduce confusion, and perhaps cause the Netbeans people to avoid putting
> > the path attribute into the context element - presumably they took the
> view
> > that it was supported?
>
> It was supported about 10 years and 4 major versions ago.
>
> > At this point may I ask what reason prevents you from supporting such a
> > deployment facility? I am surprised that so much of what I would expect
> is
> > supported, yet this pretty significant part is not. I'm curious now as to
> > why.
>
> The issue was that it lead to lots of problems when coupled with
> automatic deployment. For example, if you have foo.war and bar.war in
> your webapps directory and bar.war contains a context.xml file that
> declares a path of "/foo" what happens?
>
> Now that is a relatively simple case where the desired behaviour could
> be documented and Tomcat coded to implement it. However once all the
> moving parts are taken into account:
> - name of WAR file
> - presence (or not) of context.xml with a path defined
> - automatic deployment enabled (or not)
> - context.xml file extracted to ${CATALINA_BASE}/<enginename>/<hostname>
> (or not)
> - deployment of a new application that may (or may not conflict with
> some of the above
> - deployment order (context.xml, WAR, dir)
> - detection of changes to context.xml and automatic re-deployment
> - expansion (or not) of WAR file into corresponding directory
>
> it rapidly reached the point where the code was extremely fragile and
> still had plenty of bugs. The decision was taken, therefore, to link the
> base file name and context name as previously described. This removed
> nearly all of the nasty edge cases, made for much simpler code and made
> the overall process a lot easier to understand.
>
Fair enough. I appreciate the explanation - seems reasonable to me.
>
> > May I ask ask how deployment is usually carried out it development and
> > project environments? Is it usually doing using the HTTP api (which is I
> > presume the way Netbeans interacts with Tomcat)?
>
> Unlikely. I usually see the following process:
> - stop the instance
> - copy the WAR
> - start the instance
>
I'll admit now to now having yet read any documentation on this - but is
there a graceful shutdown procedure? Similar to apache2ctl graceful, but
one that allows threads to complete naturally whilst preventing new inbound
network connections to be accepted? I am of course thinking that such a
stop/copy/start solution must be sat behind a proxy.
>
> I rarely see production deployments deploying via HTTP. YMMV.
>
> > Thanks again for your time. I would appreciate it if the documentation
> > would clarify that the part of the webapp cannot be set within the
> deployed
> > webapp itself.
>
> I'm assuming s/part/path/
>
Indeed.
>
> I'll take a look at that shortly.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
