You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by James Green <ja...@gmail.com> on 2013/03/03 10:36:19 UTC
Context.xml ignored.
We have a war archive that includes a netbeans-generated context.xml for tomcat deployment.
If we drop this war into webapps, the context root remains that of the war filename.
Has there been a regression in recent 7.x releases in this regard?
Interestingly, a colleague confirms that this is happening also in her independent project (again in 7.x I believe).
If we run from netbeans, the context is set as expected.
Thanks,
James
Sent from my iPad
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context.xml ignored.
Posted by James Green <ja...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Context.xml ignored.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 3/3/13 1:44 PM, Mark Thomas wrote:
> 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.
It also makes things IMHO easier for deployers: if you want to change
the context path of a webapp, pretty much all you have to do is this:
$ mv oldname.war newname.war
No messing-around with "path" attributes, re-rolling WAR files, etc.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlE1U4YACgkQ9CaO5/Lv0PAnigCbBHwSK+wvi5ew5vLoI0Lq7jqI
tToAnjUN+nrMDKvb5WIH6hhs4Yux1fYG
=BFGU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context.xml ignored.
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context.xml ignored.
Posted by James Green <ja...@gmail.com>.
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?
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.
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)?
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.
James
Re: Context.xml ignored.
Posted by Mark Thomas <ma...@apache.org>.
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.
If you look up the configuration for Context elements (which you would
have to do to figure out how to define the context path for a context
element) you will see that there are limitations on when the path
attribute may be used.
> I seem not to be alone in thinking this is the case. A simple Google
> revealed:
> http://stackoverflow.com/questions/2593472/define-servlet-context-in-war-file
>
> If you are suggesting that META-INF/context.xml is not used for the
> purposes of defining the context path, then quite a few references need to
> be removed.
Where? I don't believe there are any places in the Tomcat docs where it
is stated that a context path may be configured in a context.xml file.
The docs do state that this is not the case. Perhaps we need to state
this in more places.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context.xml ignored.
Posted by Mark Eggers <it...@yahoo.com>.
On 3/3/2013 8:22 AM, James Green wrote:
> On 3 March 2013 15:51, Mark Thomas <ma...@apache.org> wrote:
>
>> On 03/03/2013 15:29, James Green wrote:
>>> On 3 March 2013 14:32, Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> On 03/03/2013 14:24, James Green wrote:
>>>>> On 3 March 2013 11:34, Konstantin Kolinko <kn...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> 2013/3/3 James Green <ja...@gmail.com>:
>>>>
>>>>> So now I have a war deployed. Easy enough. Now to set the URL path.
>>>> There a
>>>>> lot of talk about Context Descriptors on that page, and at the top one
>>>>> seems to be read from webapps/[my-war-file]/META-INF/context.xml.
>>>> Perfect,
>>>>> but what goes in it?
>>>>>
>>>>> Elsewhere, I find Config, and in there we find Context. Aha! Parallel
>>>>> Deployment? Nope don't want that. Naming? I read that several times,
>> and
>>>> I
>>>>> have no idea still what is trying to be expressed. Does it even apply
>> to
>>>>> me? Not sure, let's move on
>>>>
>>>> Stop here. The naming section is exactly the bit you need to understand.
>>>>
>>>> I'm sure there is scope to improve the docs so if you explain where you
>>>> start to get lost we can look at improving the wording / adding
>>>> additional explanation as required.
>>>> <us...@tomcat.apache.org>
>>>>
>>>
>>> Diving straight into the Naming section then we describe a relationship
>>> involving these elements:
>>>
>>> - Context Name
>>> - Context Version
>>> - Context Path
>>> - Base file name
>>>
>>> Is the base file name the name of the war file built?
>>> Are the context elements name, version and path, supposed to come from
>> the
>>> context.xml file? Other than path, they are not listed in the attributes
>>> further down the page.
>>
>> OK. Lets address the above. Once you are happy you understand what is
>> going on, I'll suggest an update to the docs that you can review.
>>
>> Context path is as defined in the Servlet specification.
>>
>> Context name is the unique identifier for a context within a host. If no
>> version is specified (none is needed unless parallel deployment is being
>> used) then context name is identical the the context path. If a version
>> is specified then ##ContextVersion is appended to the context path to
>> create the context name.
>>
>> Context version is a version identifier that is used under parallel
>> deployment when multiple versions of the same application are deployed
>> with the same context path.
>>
>> Base file name is the common part of the file named used for the WAR
>> (baseFileName.war) directory (baseFileName) or context.xml file
>> (baseFileName.xml) from which the application is deployed.
>>
>> Context name is derived from base file name by:
>> - replacing any single '#' characters with '/'
>> - if the base file name starts with "ROOT", replacing "ROOT" with the
>> empty string
>> - if the base file name does not start with "ROOT", pre-pending a
>> leading '/'
>>
>> 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.
>
> I seem not to be alone in thinking this is the case. A simple Google
> revealed:
> http://stackoverflow.com/questions/2593472/define-servlet-context-in-war-file
>
> If you are suggesting that META-INF/context.xml is not used for the
> purposes of defining the context path, then quite a few references need to
> be removed. If you are not suggesting this, then I am still missing the
> reason why my context.xml does not deploy the application to the path I
> supply.
>
> Thanks for providing your time on this matter so far.
>
> James
>
James,
Here are my thoughts as to how all this works. I use NetBeans, but I'm
more of a systems person than a developer, so your mileage may vary.
I've used UNIX conventions below for environment variables since you've
not stated what your development platform runs on.
If you've not changed the default Tomcat server.xml, then the following
is true:
[engine-name] = Catalina
[host-name] = localhost
[context-name] = name of the context
appBase = $CATALINA_BASE/webapps (%CATALINA_BASE%\webapps)
$CATALINA_BASE is where Tomcat is being run from. If you have a single
Tomcat (see RUNNING.txt for other configurations), then most likely this
value is the same as $CATALINA_HOME (where Tomcat is installed).
NetBeans runs a servlet project not by copying a WAR file to the appBase
directory, but by creating a [project-name].xml context file and copying
that to $CATALINA_BASE/conf/[engine-name]/[host-name].
I think the steps are as follows:
1. Read a project's [project-name]web/META-INF/context.xml file if any
2. Merge that information with and add the following attributes:
a. antiJARLocking="true"
b. docBase="[absolute-path-to-project]/build/web"
c. path="[context-path"]
3. Copy the resulting [project-name].xml to
$CATALINA_BASE/conf/[engine-name]/[host-name]
I'm a little fuzzy on the [project-name].xml name, since I've only ever
put together projects with names that reflect my actual desired context.
In my opinion, NetBeans should read the project properties and use the
Context Path property (in the Run category of Properties) to name the
context file. This would remove the need for 2.c above (which is almost
always incorrect).
When you build a WAR for deployment, the default WAR file name reflects
the project name. This means that when you drop the WAR file into a
Tomcat, the resulting context may be different than what you intended it
to be.
You have several choices.
1. Run the WAR file (or exploded directory) outside of the Host's
appBase and modify server.xml
This is not recommended, so I'm not detailing the configuration changes
and deployment steps you need to do this. It's documented on the Tomcat
web site, but discouraged.
2. Run the WAR file (or exploded directory) outside of the Host's
appBase and create
$CATALINA_BASE/conf/[engine-name]/[host-name]/[context-name].xml
You do this by creating your WAR file (or exploded directory), and then
copying a suitably crafted [context-name].xml to the directory mentioned
above.
This is sort of, almost exactly like, but not quite what NetBeans does
(apologies to Douglas Adams). Again, see my explanation above as to what
I think NetBeans does.
3. Rename your WAR file to be [desired-context-name].war and drop it
into the right appBase.
This is the easiest of the three cases to accomplish.
If you're using NetBeans and its standard build script, you can change
the name of the built war in Properties->Build->Packaging. The field is
(obviously enough) called WAR File:.
If you're using Maven as your build environment, you can use the
finalName element to achieve the same thing. I do this since otherwise
Maven will append the version element value to the WAR file name. In
most cases this is not what I want.
Hopefully this is helpful.
. . . . just my 2 cents
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context.xml ignored.
Posted by James Green <ja...@gmail.com>.
On 3 March 2013 15:51, Mark Thomas <ma...@apache.org> wrote:
> On 03/03/2013 15:29, James Green wrote:
> > On 3 March 2013 14:32, Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 03/03/2013 14:24, James Green wrote:
> >>> On 3 March 2013 11:34, Konstantin Kolinko <kn...@gmail.com>
> >> wrote:
> >>>
> >>>> 2013/3/3 James Green <ja...@gmail.com>:
> >>
> >>> So now I have a war deployed. Easy enough. Now to set the URL path.
> >> There a
> >>> lot of talk about Context Descriptors on that page, and at the top one
> >>> seems to be read from webapps/[my-war-file]/META-INF/context.xml.
> >> Perfect,
> >>> but what goes in it?
> >>>
> >>> Elsewhere, I find Config, and in there we find Context. Aha! Parallel
> >>> Deployment? Nope don't want that. Naming? I read that several times,
> and
> >> I
> >>> have no idea still what is trying to be expressed. Does it even apply
> to
> >>> me? Not sure, let's move on
> >>
> >> Stop here. The naming section is exactly the bit you need to understand.
> >>
> >> I'm sure there is scope to improve the docs so if you explain where you
> >> start to get lost we can look at improving the wording / adding
> >> additional explanation as required.
> >> <us...@tomcat.apache.org>
> >>
> >
> > Diving straight into the Naming section then we describe a relationship
> > involving these elements:
> >
> > - Context Name
> > - Context Version
> > - Context Path
> > - Base file name
> >
> > Is the base file name the name of the war file built?
> > Are the context elements name, version and path, supposed to come from
> the
> > context.xml file? Other than path, they are not listed in the attributes
> > further down the page.
>
> OK. Lets address the above. Once you are happy you understand what is
> going on, I'll suggest an update to the docs that you can review.
>
> Context path is as defined in the Servlet specification.
>
> Context name is the unique identifier for a context within a host. If no
> version is specified (none is needed unless parallel deployment is being
> used) then context name is identical the the context path. If a version
> is specified then ##ContextVersion is appended to the context path to
> create the context name.
>
> Context version is a version identifier that is used under parallel
> deployment when multiple versions of the same application are deployed
> with the same context path.
>
> Base file name is the common part of the file named used for the WAR
> (baseFileName.war) directory (baseFileName) or context.xml file
> (baseFileName.xml) from which the application is deployed.
>
> Context name is derived from base file name by:
> - replacing any single '#' characters with '/'
> - if the base file name starts with "ROOT", replacing "ROOT" with the
> empty string
> - if the base file name does not start with "ROOT", pre-pending a
> leading '/'
>
> 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.
I seem not to be alone in thinking this is the case. A simple Google
revealed:
http://stackoverflow.com/questions/2593472/define-servlet-context-in-war-file
If you are suggesting that META-INF/context.xml is not used for the
purposes of defining the context path, then quite a few references need to
be removed. If you are not suggesting this, then I am still missing the
reason why my context.xml does not deploy the application to the path I
supply.
Thanks for providing your time on this matter so far.
James
Re: Context.xml ignored.
Posted by Mark Thomas <ma...@apache.org>.
On 03/03/2013 15:29, James Green wrote:
> On 3 March 2013 14:32, Mark Thomas <ma...@apache.org> wrote:
>
>> On 03/03/2013 14:24, James Green wrote:
>>> On 3 March 2013 11:34, Konstantin Kolinko <kn...@gmail.com>
>> wrote:
>>>
>>>> 2013/3/3 James Green <ja...@gmail.com>:
>>
>>> So now I have a war deployed. Easy enough. Now to set the URL path.
>> There a
>>> lot of talk about Context Descriptors on that page, and at the top one
>>> seems to be read from webapps/[my-war-file]/META-INF/context.xml.
>> Perfect,
>>> but what goes in it?
>>>
>>> Elsewhere, I find Config, and in there we find Context. Aha! Parallel
>>> Deployment? Nope don't want that. Naming? I read that several times, and
>> I
>>> have no idea still what is trying to be expressed. Does it even apply to
>>> me? Not sure, let's move on
>>
>> Stop here. The naming section is exactly the bit you need to understand.
>>
>> I'm sure there is scope to improve the docs so if you explain where you
>> start to get lost we can look at improving the wording / adding
>> additional explanation as required.
>> <us...@tomcat.apache.org>
>>
>
> Diving straight into the Naming section then we describe a relationship
> involving these elements:
>
> - Context Name
> - Context Version
> - Context Path
> - Base file name
>
> Is the base file name the name of the war file built?
> Are the context elements name, version and path, supposed to come from the
> context.xml file? Other than path, they are not listed in the attributes
> further down the page.
OK. Lets address the above. Once you are happy you understand what is
going on, I'll suggest an update to the docs that you can review.
Context path is as defined in the Servlet specification.
Context name is the unique identifier for a context within a host. If no
version is specified (none is needed unless parallel deployment is being
used) then context name is identical the the context path. If a version
is specified then ##ContextVersion is appended to the context path to
create the context name.
Context version is a version identifier that is used under parallel
deployment when multiple versions of the same application are deployed
with the same context path.
Base file name is the common part of the file named used for the WAR
(baseFileName.war) directory (baseFileName) or context.xml file
(baseFileName.xml) from which the application is deployed.
Context name is derived from base file name by:
- replacing any single '#' characters with '/'
- if the base file name starts with "ROOT", replacing "ROOT" with the
empty string
- if the base file name does not start with "ROOT", pre-pending a
leading '/'
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context.xml ignored.
Posted by James Green <ja...@gmail.com>.
On 3 March 2013 14:32, Mark Thomas <ma...@apache.org> wrote:
> On 03/03/2013 14:24, James Green wrote:
> > On 3 March 2013 11:34, Konstantin Kolinko <kn...@gmail.com>
> wrote:
> >
> >> 2013/3/3 James Green <ja...@gmail.com>:
>
> > So now I have a war deployed. Easy enough. Now to set the URL path.
> There a
> > lot of talk about Context Descriptors on that page, and at the top one
> > seems to be read from webapps/[my-war-file]/META-INF/context.xml.
> Perfect,
> > but what goes in it?
> >
> > Elsewhere, I find Config, and in there we find Context. Aha! Parallel
> > Deployment? Nope don't want that. Naming? I read that several times, and
> I
> > have no idea still what is trying to be expressed. Does it even apply to
> > me? Not sure, let's move on
>
> Stop here. The naming section is exactly the bit you need to understand.
>
> I'm sure there is scope to improve the docs so if you explain where you
> start to get lost we can look at improving the wording / adding
> additional explanation as required.
> <us...@tomcat.apache.org>
>
Diving straight into the Naming section then we describe a relationship
involving these elements:
- Context Name
- Context Version
- Context Path
- Base file name
Is the base file name the name of the war file built?
Are the context elements name, version and path, supposed to come from the
context.xml file? Other than path, they are not listed in the attributes
further down the page.
So now I'm being told that a set of rules apply when no version is
specified. Still no idea where a version gets specified though: is it read
from the war filename? Going to have to ignore this for now.
Now on to something that appears reasonably clear: If you want to deploy a
WAR file or a directory using a context path that is not related to the
base file name - yes! then one of the following options must be used to
prevent double-deployment - double deployment? Does this still apply to
deployment in general or some particular circumstance in which
double-deployment would happen?
Disable autoDeploy and deployOnStartup and define all Contexts in
server.xml - given the dynamic nature of our development, that is
definitely not desirable
Locate the WAR and/or directory outside of the Host's appBase and use a
context.xml file with a docBase attribute to define it. - you want me to
hook in the war from outside Tomcat? Not clear why I would want to do that.
If I may digress some further: Looking at the FAQ, under Deployment, I'm am
told that META-INF/context.xml is still recommended for Tomcat 7. I am
still left wondering what I should be doing...
James
Re: Context.xml ignored.
Posted by Mark Thomas <ma...@apache.org>.
On 03/03/2013 14:24, James Green wrote:
> On 3 March 2013 11:34, Konstantin Kolinko <kn...@gmail.com> wrote:
>
>> 2013/3/3 James Green <ja...@gmail.com>:
>>> We have a war archive that includes a netbeans-generated context.xml for
>> tomcat deployment.
>>>
>>> If we drop this war into webapps, the context root remains that of the
>> war filename.
>>
>> As expected, in any of 7.0., 6.0 and even 5.5 .
>> Have you read the docs (Context chapter in Configuration reference)?
>>
>
> I did. Allow me to digress a little to provide insight into how I read the
> documentation.
>
> First I got to the main documentation and click section 4: Deployer. Scroll
> down to "Deploying on a running Tomcat server" - this is exactly what I
> want. I read that provided autoDeploy is set to true Tomcat will unpack
> .war files deployed to something called appBase - this seems to mean the
> webapps folder when Googling around for application deployment directory in
> Tomcat. No idea at this point if autoDeploy is true or not, one way to find
> out - try it. Sure enough the war file gets consumed.
OK. So autoDeploy is true. This is the default setting. Look for it in
your server.xml and you'll find it is explicitly set (on the Host). You
can also look at the host docs for confirmation.
> So now I have a war deployed. Easy enough. Now to set the URL path. There a
> lot of talk about Context Descriptors on that page, and at the top one
> seems to be read from webapps/[my-war-file]/META-INF/context.xml. Perfect,
> but what goes in it?
>
> Elsewhere, I find Config, and in there we find Context. Aha! Parallel
> Deployment? Nope don't want that. Naming? I read that several times, and I
> have no idea still what is trying to be expressed. Does it even apply to
> me? Not sure, let's move on
Stop here. The naming section is exactly the bit you need to understand.
I'm sure there is scope to improve the docs so if you explain where you
start to get lost we can look at improving the wording / adding
additional explanation as required.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context.xml ignored.
Posted by James Green <ja...@gmail.com>.
On 3 March 2013 11:34, Konstantin Kolinko <kn...@gmail.com> wrote:
> 2013/3/3 James Green <ja...@gmail.com>:
> > We have a war archive that includes a netbeans-generated context.xml for
> tomcat deployment.
> >
> > If we drop this war into webapps, the context root remains that of the
> war filename.
>
> As expected, in any of 7.0., 6.0 and even 5.5 .
> Have you read the docs (Context chapter in Configuration reference)?
>
I did. Allow me to digress a little to provide insight into how I read the
documentation.
First I got to the main documentation and click section 4: Deployer. Scroll
down to "Deploying on a running Tomcat server" - this is exactly what I
want. I read that provided autoDeploy is set to true Tomcat will unpack
.war files deployed to something called appBase - this seems to mean the
webapps folder when Googling around for application deployment directory in
Tomcat. No idea at this point if autoDeploy is true or not, one way to find
out - try it. Sure enough the war file gets consumed.
So now I have a war deployed. Easy enough. Now to set the URL path. There a
lot of talk about Context Descriptors on that page, and at the top one
seems to be read from webapps/[my-war-file]/META-INF/context.xml. Perfect,
but what goes in it?
Elsewhere, I find Config, and in there we find Context. Aha! Parallel
Deployment? Nope don't want that. Naming? I read that several times, and I
have no idea still what is trying to be expressed. Does it even apply to
me? Not sure, let's move on and see if anything else seems directly related
to what I'm doing. Defining a Context: That's what I want. First option -
META/INF/context.xml. Aha. Do we have an example with sensible example
values to change? No. OK, let's see if Netbeans can help out. Set the
project to run inside Tomcat, and deploy to my named context path. After
running, I have a META-INF/context.xml with a couple of attributes that
match the documentation.
Perfect. I can deploy from Netbeans, but still deploying by dropping into
the webapps folder doesn't have the fully desired effect. If I do the same
with Glassfish using it's config file, I do get the desired effect. Seems
simple enough... Wonder what's different...
OK I've digressed enough, and still I've not spotted anything clear and
concise telling me what I'm doing wrong.
Apologies if I am being really, really, blind!
Thanks,
James
Re: Context.xml ignored.
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/3/3 James Green <ja...@gmail.com>:
> We have a war archive that includes a netbeans-generated context.xml for tomcat deployment.
>
> If we drop this war into webapps, the context root remains that of the war filename.
As expected, in any of 7.0., 6.0 and even 5.5 .
Have you read the docs (Context chapter in Configuration reference)?
>
> Has there been a regression in recent 7.x releases in this regard?
>
> Interestingly, a colleague confirms that this is happening also in her independent project (again in 7.x I believe).
>
> If we run from netbeans, the context is set as expected.
>
> Thanks,
>
> James
>
> Sent from my iPad
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org