You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Paul Benedict <pb...@apache.org> on 2016/03/17 17:06:10 UTC
"Distinct and non-overlapping" context roots
This question is not about Tomcat per se, but it does affect it. It's
really about the EE specification in regards to any servlet container. I'd
like to get professional opinions on this part of the specification.
I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph 3c:
The Deployer must... "Assign a context root for each web module included in
the Java EE application. The context root is a relative name in the web
namespace for the application. Each web module must be given a distinct and
non-overlapping name for its context root."
So given this scenario:
/context/something <-- context is /context
/context/something/somethingelse <-- context is /context/something
The specification puts no limitations on the context root character set (so
it can include a slash). With that said, would you consider these
"overlapping" contexts? I noticed one application server supporting this
paradigm without issue, but it seems like a violation of the specification.
Please advise.
Also, since Tomcat doesn't support "applications" (EAR?), how should the
specification be interpreted in the absence of that artifact?
[1] http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
Cheers,
Paul
Re: "Distinct and non-overlapping" context roots
Posted by Paul Benedict <pb...@apache.org>.
By the way, I should mention that with Apache AJP in front of a container,
this kind of partial matching stuff gets really interesting. :-)
Cheers,
Paul
On Tue, Mar 22, 2016 at 11:47 AM, Paul Benedict <pb...@apache.org>
wrote:
> Yes, I gave them the same example I used here. They confirmed it is
> "overlapping". Here is the example again:
>
> /context/something <-- context is /context
> /context/something/somethingelse <-- context is /context/something
>
> Cheers,
> Paul
>
> On Tue, Mar 22, 2016 at 11:34 AM, David kerber <dc...@verizon.net>
> wrote:
>
>> On 3/22/2016 12:31 PM, Paul Benedict wrote:
>>
>>> Mark, I did get some clarification. Thanks for asking.
>>>
>>> The EE spec states an "application" may not have overlapping context
>>> roots.
>>> I got clarification that "application" refers only to an EAR. Therefore,
>>> an
>>> EE server should be validating this condition.
>>>
>>
>> I've been following this thread just a bit, and have a question about
>> it: what does "overlapping" mean to them? To me, if one was a subset
>> (completely contained inside) of another one, that would not be
>> overlapping. Overlapping would imply that two apps would both match some
>> URLs, while other URLs would only match one or the other. Is that how they
>> define overlapping?
>>
>>
Re: "Distinct and non-overlapping" context roots
Posted by Paul Benedict <pb...@apache.org>.
Yes, I gave them the same example I used here. They confirmed it is
"overlapping". Here is the example again:
/context/something <-- context is /context
/context/something/somethingelse <-- context is /context/something
Cheers,
Paul
On Tue, Mar 22, 2016 at 11:34 AM, David kerber <dc...@verizon.net> wrote:
> On 3/22/2016 12:31 PM, Paul Benedict wrote:
>
>> Mark, I did get some clarification. Thanks for asking.
>>
>> The EE spec states an "application" may not have overlapping context
>> roots.
>> I got clarification that "application" refers only to an EAR. Therefore,
>> an
>> EE server should be validating this condition.
>>
>
> I've been following this thread just a bit, and have a question about it:
> what does "overlapping" mean to them? To me, if one was a subset
> (completely contained inside) of another one, that would not be
> overlapping. Overlapping would imply that two apps would both match some
> URLs, while other URLs would only match one or the other. Is that how they
> define overlapping?
>
>
Re: "Distinct and non-overlapping" context roots
Posted by David kerber <dc...@verizon.net>.
On 3/22/2016 12:31 PM, Paul Benedict wrote:
> Mark, I did get some clarification. Thanks for asking.
>
> The EE spec states an "application" may not have overlapping context roots.
> I got clarification that "application" refers only to an EAR. Therefore, an
> EE server should be validating this condition.
I've been following this thread just a bit, and have a question about
it: what does "overlapping" mean to them? To me, if one was a subset
(completely contained inside) of another one, that would not be
overlapping. Overlapping would imply that two apps would both match
some URLs, while other URLs would only match one or the other. Is that
how they define overlapping?
>
> So two inferences follow:
> 1) In the case of an EAR bundling a WAR that specifies the root context, no
> other WAR can be allowed in the EAR since any other context would overlap
> with the root context.
> 2) Without an EAR, there are no overlapping restrictions except for
> (obviously) identical context roots.
>
> And two extra pieces of information worth knowing:
> a) Supposedly GlassFish imposes the "overlapping" restriction on the entire
> application server, not just the EAR.
> b) The specification doesn't prevent the slash character in the context
> name, but I got the distinct impression that's something to fix in the
> future.
>
> Cheers,
> Paul
>
> On Tue, Mar 22, 2016 at 11:12 AM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 22/03/2016 15:57, Paul Benedict wrote:
>>> FYI, the EE spec lead and Servlet spec lead consulted. They said I should
>>> log a ticket against the Servlet specification on this matter. That is
>>> something I think I shall do. I found some wording in the specification
>>> that should likely have more detail.
>>
>> Did you get any clarity on what the Java EE spec authours actually meant?
>>
>> Mark
>>
>>>
>>> Cheers,
>>> Paul
>>>
>>> On Tue, Mar 22, 2016 at 10:49 AM, Mark Thomas <ma...@homeinbox.net>
>> wrote:
>>>
>>>> On 22 March 2016 14:46:31 GMT+00:00, Christopher Schultz <
>>>> chris@christopherschultz.net> wrote:
>>>>> Mark,
>>>>>
>>>>> On 3/17/16 1:28 PM, Mark Thomas wrote:
>>>>>> On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict
>>>>> <pb...@apache.org> wrote:
>>>>>>> This question is not about Tomcat per se, but it does affect it.
>>>>> It's
>>>>>>> really about the EE specification in regards to any servlet
>>>>> container.
>>>>>>> I'd
>>>>>>> like to get professional opinions on this part of the specification.
>>>>>>>
>>>>>>> I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph
>>>>> 3c:
>>>>>>>
>>>>>>> The Deployer must... "Assign a context root for each web module
>>>>>>> included in
>>>>>>> the Java EE application. The context root is a relative name in the
>>>>> web
>>>>>>> namespace for the application. Each web module must be given a
>>>>> distinct
>>>>>>> and
>>>>>>> non-overlapping name for its context root."
>>>>>>>
>>>>>>> So given this scenario:
>>>>>>> /context/something <-- context is /context
>>>>>>> /context/something/somethingelse <-- context is /context/something
>>>>>>>
>>>>>>> The specification puts no limitations on the context root character
>>>>> set
>>>>>>> (so
>>>>>>> it can include a slash). With that said, would you consider these
>>>>>>> "overlapping" contexts? I noticed one application server supporting
>>>>>>> this
>>>>>>> paradigm without issue, but it seems like a violation of the
>>>>>>> specification.
>>>>>>> Please advise.
>>>>>>>
>>>>>>> Also, since Tomcat doesn't support "applications" (EAR?), how should
>>>>>>> the
>>>>>>> specification be interpreted in the absence of that artifact?
>>>>>>>
>>>>>>> [1]
>>>>>>> http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Paul
>>>>>>
>>>>>> That requirement makes no sense as I understand it. You always have
>>>>> overlapping context paths because of the ROOT context.
>>>>>>
>>>>>> I think this is one for the EG to clarify what they meant.
>>>>>>
>>>>>> It is also worth noting that the servlet spec explicitly states thst
>>>>>> requests are matched against the longest matching context path.
>>>>>
>>>>> How can Tomcat tell the difference between requests to:
>>>>>
>>>>> /webappA/someresource/foo (which does exist in webappA path=/webappA)
>>>>> and
>>>>> /webappA/someresource/foo (which does not exist in webappB
>>>>> path="/webappA/someresource)
>>>>>
>>>>> In the above case, Tomcat should choose the second, because
>>>>> /webappA/someresource matches webappB's context path, which is longer
>>>>> than webappA's context path, right?
>>>>
>>>> Correct. That should result in a 404.
>>>>
>>>> We've use this trick to return something useful if a user requests the
>>>> docs Web app when it isn't installed.
>>>>
>>>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: "Distinct and non-overlapping" context roots
Posted by Paul Benedict <pb...@apache.org>.
Mark, I did get some clarification. Thanks for asking.
The EE spec states an "application" may not have overlapping context roots.
I got clarification that "application" refers only to an EAR. Therefore, an
EE server should be validating this condition.
So two inferences follow:
1) In the case of an EAR bundling a WAR that specifies the root context, no
other WAR can be allowed in the EAR since any other context would overlap
with the root context.
2) Without an EAR, there are no overlapping restrictions except for
(obviously) identical context roots.
And two extra pieces of information worth knowing:
a) Supposedly GlassFish imposes the "overlapping" restriction on the entire
application server, not just the EAR.
b) The specification doesn't prevent the slash character in the context
name, but I got the distinct impression that's something to fix in the
future.
Cheers,
Paul
On Tue, Mar 22, 2016 at 11:12 AM, Mark Thomas <ma...@apache.org> wrote:
> On 22/03/2016 15:57, Paul Benedict wrote:
> > FYI, the EE spec lead and Servlet spec lead consulted. They said I should
> > log a ticket against the Servlet specification on this matter. That is
> > something I think I shall do. I found some wording in the specification
> > that should likely have more detail.
>
> Did you get any clarity on what the Java EE spec authours actually meant?
>
> Mark
>
> >
> > Cheers,
> > Paul
> >
> > On Tue, Mar 22, 2016 at 10:49 AM, Mark Thomas <ma...@homeinbox.net>
> wrote:
> >
> >> On 22 March 2016 14:46:31 GMT+00:00, Christopher Schultz <
> >> chris@christopherschultz.net> wrote:
> >>> Mark,
> >>>
> >>> On 3/17/16 1:28 PM, Mark Thomas wrote:
> >>>> On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict
> >>> <pb...@apache.org> wrote:
> >>>>> This question is not about Tomcat per se, but it does affect it.
> >>> It's
> >>>>> really about the EE specification in regards to any servlet
> >>> container.
> >>>>> I'd
> >>>>> like to get professional opinions on this part of the specification.
> >>>>>
> >>>>> I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph
> >>> 3c:
> >>>>>
> >>>>> The Deployer must... "Assign a context root for each web module
> >>>>> included in
> >>>>> the Java EE application. The context root is a relative name in the
> >>> web
> >>>>> namespace for the application. Each web module must be given a
> >>> distinct
> >>>>> and
> >>>>> non-overlapping name for its context root."
> >>>>>
> >>>>> So given this scenario:
> >>>>> /context/something <-- context is /context
> >>>>> /context/something/somethingelse <-- context is /context/something
> >>>>>
> >>>>> The specification puts no limitations on the context root character
> >>> set
> >>>>> (so
> >>>>> it can include a slash). With that said, would you consider these
> >>>>> "overlapping" contexts? I noticed one application server supporting
> >>>>> this
> >>>>> paradigm without issue, but it seems like a violation of the
> >>>>> specification.
> >>>>> Please advise.
> >>>>>
> >>>>> Also, since Tomcat doesn't support "applications" (EAR?), how should
> >>>>> the
> >>>>> specification be interpreted in the absence of that artifact?
> >>>>>
> >>>>> [1]
> >>>>> http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
> >>>>>
> >>>>> Cheers,
> >>>>> Paul
> >>>>
> >>>> That requirement makes no sense as I understand it. You always have
> >>> overlapping context paths because of the ROOT context.
> >>>>
> >>>> I think this is one for the EG to clarify what they meant.
> >>>>
> >>>> It is also worth noting that the servlet spec explicitly states thst
> >>>> requests are matched against the longest matching context path.
> >>>
> >>> How can Tomcat tell the difference between requests to:
> >>>
> >>> /webappA/someresource/foo (which does exist in webappA path=/webappA)
> >>> and
> >>> /webappA/someresource/foo (which does not exist in webappB
> >>> path="/webappA/someresource)
> >>>
> >>> In the above case, Tomcat should choose the second, because
> >>> /webappA/someresource matches webappB's context path, which is longer
> >>> than webappA's context path, right?
> >>
> >> Correct. That should result in a 404.
> >>
> >> We've use this trick to return something useful if a user requests the
> >> docs Web app when it isn't installed.
> >>
> >> 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: "Distinct and non-overlapping" context roots
Posted by Mark Thomas <ma...@apache.org>.
On 22/03/2016 15:57, Paul Benedict wrote:
> FYI, the EE spec lead and Servlet spec lead consulted. They said I should
> log a ticket against the Servlet specification on this matter. That is
> something I think I shall do. I found some wording in the specification
> that should likely have more detail.
Did you get any clarity on what the Java EE spec authours actually meant?
Mark
>
> Cheers,
> Paul
>
> On Tue, Mar 22, 2016 at 10:49 AM, Mark Thomas <ma...@homeinbox.net> wrote:
>
>> On 22 March 2016 14:46:31 GMT+00:00, Christopher Schultz <
>> chris@christopherschultz.net> wrote:
>>> Mark,
>>>
>>> On 3/17/16 1:28 PM, Mark Thomas wrote:
>>>> On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict
>>> <pb...@apache.org> wrote:
>>>>> This question is not about Tomcat per se, but it does affect it.
>>> It's
>>>>> really about the EE specification in regards to any servlet
>>> container.
>>>>> I'd
>>>>> like to get professional opinions on this part of the specification.
>>>>>
>>>>> I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph
>>> 3c:
>>>>>
>>>>> The Deployer must... "Assign a context root for each web module
>>>>> included in
>>>>> the Java EE application. The context root is a relative name in the
>>> web
>>>>> namespace for the application. Each web module must be given a
>>> distinct
>>>>> and
>>>>> non-overlapping name for its context root."
>>>>>
>>>>> So given this scenario:
>>>>> /context/something <-- context is /context
>>>>> /context/something/somethingelse <-- context is /context/something
>>>>>
>>>>> The specification puts no limitations on the context root character
>>> set
>>>>> (so
>>>>> it can include a slash). With that said, would you consider these
>>>>> "overlapping" contexts? I noticed one application server supporting
>>>>> this
>>>>> paradigm without issue, but it seems like a violation of the
>>>>> specification.
>>>>> Please advise.
>>>>>
>>>>> Also, since Tomcat doesn't support "applications" (EAR?), how should
>>>>> the
>>>>> specification be interpreted in the absence of that artifact?
>>>>>
>>>>> [1]
>>>>> http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
>>>>>
>>>>> Cheers,
>>>>> Paul
>>>>
>>>> That requirement makes no sense as I understand it. You always have
>>> overlapping context paths because of the ROOT context.
>>>>
>>>> I think this is one for the EG to clarify what they meant.
>>>>
>>>> It is also worth noting that the servlet spec explicitly states thst
>>>> requests are matched against the longest matching context path.
>>>
>>> How can Tomcat tell the difference between requests to:
>>>
>>> /webappA/someresource/foo (which does exist in webappA path=/webappA)
>>> and
>>> /webappA/someresource/foo (which does not exist in webappB
>>> path="/webappA/someresource)
>>>
>>> In the above case, Tomcat should choose the second, because
>>> /webappA/someresource matches webappB's context path, which is longer
>>> than webappA's context path, right?
>>
>> Correct. That should result in a 404.
>>
>> We've use this trick to return something useful if a user requests the
>> docs Web app when it isn't installed.
>>
>> 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: "Distinct and non-overlapping" context roots
Posted by Paul Benedict <pb...@apache.org>.
FYI, the EE spec lead and Servlet spec lead consulted. They said I should
log a ticket against the Servlet specification on this matter. That is
something I think I shall do. I found some wording in the specification
that should likely have more detail.
Cheers,
Paul
On Tue, Mar 22, 2016 at 10:49 AM, Mark Thomas <ma...@homeinbox.net> wrote:
> On 22 March 2016 14:46:31 GMT+00:00, Christopher Schultz <
> chris@christopherschultz.net> wrote:
> >Mark,
> >
> >On 3/17/16 1:28 PM, Mark Thomas wrote:
> >> On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict
> ><pb...@apache.org> wrote:
> >>> This question is not about Tomcat per se, but it does affect it.
> >It's
> >>> really about the EE specification in regards to any servlet
> >container.
> >>> I'd
> >>> like to get professional opinions on this part of the specification.
> >>>
> >>> I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph
> >3c:
> >>>
> >>> The Deployer must... "Assign a context root for each web module
> >>> included in
> >>> the Java EE application. The context root is a relative name in the
> >web
> >>> namespace for the application. Each web module must be given a
> >distinct
> >>> and
> >>> non-overlapping name for its context root."
> >>>
> >>> So given this scenario:
> >>> /context/something <-- context is /context
> >>> /context/something/somethingelse <-- context is /context/something
> >>>
> >>> The specification puts no limitations on the context root character
> >set
> >>> (so
> >>> it can include a slash). With that said, would you consider these
> >>> "overlapping" contexts? I noticed one application server supporting
> >>> this
> >>> paradigm without issue, but it seems like a violation of the
> >>> specification.
> >>> Please advise.
> >>>
> >>> Also, since Tomcat doesn't support "applications" (EAR?), how should
> >>> the
> >>> specification be interpreted in the absence of that artifact?
> >>>
> >>> [1]
> >>> http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
> >>>
> >>> Cheers,
> >>> Paul
> >>
> >> That requirement makes no sense as I understand it. You always have
> >overlapping context paths because of the ROOT context.
> >>
> >> I think this is one for the EG to clarify what they meant.
> >>
> >> It is also worth noting that the servlet spec explicitly states thst
> >> requests are matched against the longest matching context path.
> >
> >How can Tomcat tell the difference between requests to:
> >
> >/webappA/someresource/foo (which does exist in webappA path=/webappA)
> >and
> >/webappA/someresource/foo (which does not exist in webappB
> >path="/webappA/someresource)
> >
> >In the above case, Tomcat should choose the second, because
> >/webappA/someresource matches webappB's context path, which is longer
> >than webappA's context path, right?
>
> Correct. That should result in a 404.
>
> We've use this trick to return something useful if a user requests the
> docs Web app when it isn't installed.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: "Distinct and non-overlapping" context roots
Posted by Mark Thomas <ma...@homeinbox.net>.
On 22 March 2016 14:46:31 GMT+00:00, Christopher Schultz <ch...@christopherschultz.net> wrote:
>Mark,
>
>On 3/17/16 1:28 PM, Mark Thomas wrote:
>> On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict
><pb...@apache.org> wrote:
>>> This question is not about Tomcat per se, but it does affect it.
>It's
>>> really about the EE specification in regards to any servlet
>container.
>>> I'd
>>> like to get professional opinions on this part of the specification.
>>>
>>> I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph
>3c:
>>>
>>> The Deployer must... "Assign a context root for each web module
>>> included in
>>> the Java EE application. The context root is a relative name in the
>web
>>> namespace for the application. Each web module must be given a
>distinct
>>> and
>>> non-overlapping name for its context root."
>>>
>>> So given this scenario:
>>> /context/something <-- context is /context
>>> /context/something/somethingelse <-- context is /context/something
>>>
>>> The specification puts no limitations on the context root character
>set
>>> (so
>>> it can include a slash). With that said, would you consider these
>>> "overlapping" contexts? I noticed one application server supporting
>>> this
>>> paradigm without issue, but it seems like a violation of the
>>> specification.
>>> Please advise.
>>>
>>> Also, since Tomcat doesn't support "applications" (EAR?), how should
>>> the
>>> specification be interpreted in the absence of that artifact?
>>>
>>> [1]
>>> http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
>>>
>>> Cheers,
>>> Paul
>>
>> That requirement makes no sense as I understand it. You always have
>overlapping context paths because of the ROOT context.
>>
>> I think this is one for the EG to clarify what they meant.
>>
>> It is also worth noting that the servlet spec explicitly states thst
>> requests are matched against the longest matching context path.
>
>How can Tomcat tell the difference between requests to:
>
>/webappA/someresource/foo (which does exist in webappA path=/webappA)
>and
>/webappA/someresource/foo (which does not exist in webappB
>path="/webappA/someresource)
>
>In the above case, Tomcat should choose the second, because
>/webappA/someresource matches webappB's context path, which is longer
>than webappA's context path, right?
Correct. That should result in a 404.
We've use this trick to return something useful if a user requests the docs Web app when it isn't installed.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: "Distinct and non-overlapping" context roots
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 3/17/16 1:28 PM, Mark Thomas wrote:
> On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict <pb...@apache.org> wrote:
>> This question is not about Tomcat per se, but it does affect it. It's
>> really about the EE specification in regards to any servlet container.
>> I'd
>> like to get professional opinions on this part of the specification.
>>
>> I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph 3c:
>>
>> The Deployer must... "Assign a context root for each web module
>> included in
>> the Java EE application. The context root is a relative name in the web
>> namespace for the application. Each web module must be given a distinct
>> and
>> non-overlapping name for its context root."
>>
>> So given this scenario:
>> /context/something <-- context is /context
>> /context/something/somethingelse <-- context is /context/something
>>
>> The specification puts no limitations on the context root character set
>> (so
>> it can include a slash). With that said, would you consider these
>> "overlapping" contexts? I noticed one application server supporting
>> this
>> paradigm without issue, but it seems like a violation of the
>> specification.
>> Please advise.
>>
>> Also, since Tomcat doesn't support "applications" (EAR?), how should
>> the
>> specification be interpreted in the absence of that artifact?
>>
>> [1]
>> http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
>>
>> Cheers,
>> Paul
>
> That requirement makes no sense as I understand it. You always have overlapping context paths because of the ROOT context.
>
> I think this is one for the EG to clarify what they meant.
>
> It is also worth noting that the servlet spec explicitly states thst
> requests are matched against the longest matching context path.
How can Tomcat tell the difference between requests to:
/webappA/someresource/foo (which does exist in webappA path=/webappA)
and
/webappA/someresource/foo (which does not exist in webappB
path="/webappA/someresource)
In the above case, Tomcat should choose the second, because
/webappA/someresource matches webappB's context path, which is longer
than webappA's context path, right?
(This is yet another reason why confusing URL prefixes should be avoided
whenever possible.)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: "Distinct and non-overlapping" context roots
Posted by Mark Thomas <ma...@homeinbox.net>.
On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict <pb...@apache.org> wrote:
>This question is not about Tomcat per se, but it does affect it. It's
>really about the EE specification in regards to any servlet container.
>I'd
>like to get professional opinions on this part of the specification.
>
>I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph 3c:
>
>The Deployer must... "Assign a context root for each web module
>included in
>the Java EE application. The context root is a relative name in the web
>namespace for the application. Each web module must be given a distinct
>and
>non-overlapping name for its context root."
>
>So given this scenario:
>/context/something <-- context is /context
>/context/something/somethingelse <-- context is /context/something
>
>The specification puts no limitations on the context root character set
>(so
>it can include a slash). With that said, would you consider these
>"overlapping" contexts? I noticed one application server supporting
>this
>paradigm without issue, but it seems like a violation of the
>specification.
>Please advise.
>
>Also, since Tomcat doesn't support "applications" (EAR?), how should
>the
>specification be interpreted in the absence of that artifact?
>
>[1]
>http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
>
>Cheers,
>Paul
That requirement makes no sense as I understand it. You always have overlapping context paths because of the ROOT context.
I think this is one for the EG to clarify what they meant.
It is also worth noting that the servlet spec explicitly states thst requests are matched against the longest matching context path.
Mark