On 03/03/2013 19:25, James Green wrote:
> On 3 March 2013 17:58, Mark Thomas <ma...@apache.org> wrote:
>
>> On 03/03/2013 16:22, James Green wrote:
>>> On 3 March 2013 15:51, Mark Thomas <ma...@apache.org> wrote:
>>
>> <snip/>
>>
>>>> The base file name controls the context path. If you want to change the
>>>> context path, the simplest solution is to change the base file name.
>>>
>>> Fine. But this is not as described on this page:
>>> http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html
>>>
>>> Here, again, i'm told that META-INF/context.xml provides the context
>>> descriptor. It also states that dropping the war into webapps/ will
>> consume
>>> the web application.
>>>
>>> Again, in the FAQ, there holds a reference to this file for deployment
>>> purposes.
>>
>> OK. Where on that page does it say that the context.xml file is used to
>> define the context path? Maybe an explicit statement that this is not
>> the case is required.
>>
>
> 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.
> 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 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/
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
