"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
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 wrote: > 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 > > 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: "Distinct and non-overlapping" context roots
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 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 > wrote: > > > >> 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 > >>> 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-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: "Distinct and non-overlapping" context roots
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 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
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 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 > 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? >> >>