Re: "Distinct and non-overlapping" context roots

[Paul Benedict]

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?
>>
>>

Re: "Distinct and non-overlapping" context roots

[Paul Benedict]

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

[David kerber]

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  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







-
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

[Paul Benedict]

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

[Mark Thomas]

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

[Paul Benedict]

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 Thomas]

On 22 March 2016 14:46:31 GMT+00:00, Christopher Schultz 
 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

[Christopher Schultz]

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?

(This is yet another reason why confusing URL prefixes should be avoided
whenever possible.)

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

"Distinct and non-overlapping" context roots

[Paul Benedict]

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

[Mark Thomas]

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.

Mark