Re: Extensions more important than resource type in servlet resolution?

[Alexander Klimetschek <ak...@day.com>]

On Mon, May 17, 2010 at 13:55, Felix Meschberger <fm...@gmail.com> wrote:
> The observed behaviour is correct, because the more details of a request
> match what the registered servlet supports, the more weight the servlet
> becomes.
>
> Thus in the Servlet A case, only the method name matches, while in the
> Servlet B case the method (implicitly GET) and the request extension
> match. Thus Servlet B must be selected even though it is defined higher
> up in the resource type hierarchy.
>
> Compare this to Java where also the best matching method is slected from
> the class hierarchy regardless of where in the hierarchy the method placed.

After a chat with Felix we came to the conclusion that this is an
unfortunate specific case, where it seems wrong, but can't be seen as
a bug in Sling.

The problem is amplified by:
- servlet B being registered for the default resource type (which is
always dangerous and must be done with care)
- servlet A not being registered for extensions

The solution in this case is to do the latter, and either try to
register servlet B for specific resource types, if possible, or make
the accepts() method handling more specific (which works based on
paths in this case and is the simplest solution here).

Conclusion: watch your default servlet registrations. Specific
resource type scrips without extensions/selectors loose against
default servlets with specific extensions/selectors!

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Extensions more important than resource type in servlet resolution?

[Alexander Klimetschek <ak...@day.com>]

On Mon, May 17, 2010 at 17:21, Justin Edelson <ju...@gmail.com> wrote:
> I have some quibbles with the semantics here, but they're nit-picky and
> unimportant. In any case, I get it. Thanks for the explanation.
>
> I'm not sure I understand your analogy to Java object hierarchies, but
> that's OK. Chalk it up to the fact that it is Monday.

After thinking and talking about this, it's clear that any other rules
would be very difficult to implement (and get very complex...). The
way it works now is ok. And sometimes you do want to use the default
servlet for such things as in this case.

The problem was that both servlet registrations are "too" lose, and
yes, in those cases such conflicts/ties will occur.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Extensions more important than resource type in servlet resolution?

[Justin Edelson <ju...@gmail.com>]

On 5/17/10 10:50 AM, Felix Meschberger wrote:
> Hi
> 
> On 17.05.2010 15:22, Justin Edelson wrote:
>> On 5/17/10 8:19 AM, Alexander Klimetschek wrote:
>>> On Mon, May 17, 2010 at 13:55, Felix Meschberger <fm...@gmail.com> wrote:
>>>> The observed behaviour is correct, because the more details of a request
>>>> match what the registered servlet supports, the more weight the servlet
>>>> becomes.
>>>>
>>>> Thus in the Servlet A case, only the method name matches, while in the
>>>> Servlet B case the method (implicitly GET) and the request extension
>>>> match. Thus Servlet B must be selected even though it is defined higher
>>>> up in the resource type hierarchy.
>>>>
>>>> Compare this to Java where also the best matching method is slected from
>>>> the class hierarchy regardless of where in the hierarchy the method placed.
>>>
>>> After a chat with Felix we came to the conclusion that this is an
>>> unfortunate specific case, where it seems wrong, but can't be seen as
>>> a bug in Sling.
>>>
>>> The problem is amplified by:
>>> - servlet B being registered for the default resource type (which is
>>> always dangerous and must be done with care)
>>> - servlet A not being registered for extensions
>>>
>>> The solution in this case is to do the latter, and either try to
>>> register servlet B for specific resource types, if possible, or make
>>> the accepts() method handling more specific (which works based on
>>> paths in this case and is the simplest solution here).
>>>
>>> Conclusion: watch your default servlet registrations. Specific
>>> resource type scrips without extensions/selectors loose against
>>> default servlets with specific extensions/selectors!
>>>
>>> Regards,
>>> Alex
>>>
>> Hmmm. I'm not convinced this isn't a bug. Both Servlet A and Servlet B
>> match two criteria (resource type and method in the case of Servlet A
>> and extension and method in the case of Servlet B). In the case of a
>> "tie" like this, shouldn't we put more weight behind the resource type?
> 
> This isn't a tie.
> 
> The resource resolver is currently built to not give any special weight
> to the resource type.
> 
> Most weight is attributed to the request method.
> 
> Second most weight is attributed to the extension.
> 
> If more than one servlet matches for the extension, the next level of
> weight is put on the number of selectors matched. More matching
> selectors means more weight.
> 
> If extensions and selectors match, the most specific resource type wins.
> 
> In this situations we have:
> 
>   (1) request methods are the same -- GET -- tie
>   (2) request extension matches for Servlet B, Servlet A has no specific
>          request extension.
> 
> Tie resolved, Servlet B wins for more specific request extension.
> 
> This has always been like this and it always worked perfectly.
> 
> As I said, this is comparable to Java object hierarchies and method
> overloading and extension. In this respect Servlet B has to "win", too,
> since it has a more specific method to handle the request, even though
> the type is less specific. But this works as designed and desired.
> 
> Regards
> Felix
> 
I have some quibbles with the semantics here, but they're nit-picky and
unimportant. In any case, I get it. Thanks for the explanation.

I'm not sure I understand your analogy to Java object hierarchies, but
that's OK. Chalk it up to the fact that it is Monday.

Thanks,
Justin

> 
>>
>> Justin
>>

Re: Extensions more important than resource type in servlet resolution?

[Felix Meschberger <fm...@gmail.com>]

Hi

On 17.05.2010 15:22, Justin Edelson wrote:
> On 5/17/10 8:19 AM, Alexander Klimetschek wrote:
>> On Mon, May 17, 2010 at 13:55, Felix Meschberger <fm...@gmail.com> wrote:
>>> The observed behaviour is correct, because the more details of a request
>>> match what the registered servlet supports, the more weight the servlet
>>> becomes.
>>>
>>> Thus in the Servlet A case, only the method name matches, while in the
>>> Servlet B case the method (implicitly GET) and the request extension
>>> match. Thus Servlet B must be selected even though it is defined higher
>>> up in the resource type hierarchy.
>>>
>>> Compare this to Java where also the best matching method is slected from
>>> the class hierarchy regardless of where in the hierarchy the method placed.
>>
>> After a chat with Felix we came to the conclusion that this is an
>> unfortunate specific case, where it seems wrong, but can't be seen as
>> a bug in Sling.
>>
>> The problem is amplified by:
>> - servlet B being registered for the default resource type (which is
>> always dangerous and must be done with care)
>> - servlet A not being registered for extensions
>>
>> The solution in this case is to do the latter, and either try to
>> register servlet B for specific resource types, if possible, or make
>> the accepts() method handling more specific (which works based on
>> paths in this case and is the simplest solution here).
>>
>> Conclusion: watch your default servlet registrations. Specific
>> resource type scrips without extensions/selectors loose against
>> default servlets with specific extensions/selectors!
>>
>> Regards,
>> Alex
>>
> Hmmm. I'm not convinced this isn't a bug. Both Servlet A and Servlet B
> match two criteria (resource type and method in the case of Servlet A
> and extension and method in the case of Servlet B). In the case of a
> "tie" like this, shouldn't we put more weight behind the resource type?

This isn't a tie.

The resource resolver is currently built to not give any special weight
to the resource type.

Most weight is attributed to the request method.

Second most weight is attributed to the extension.

If more than one servlet matches for the extension, the next level of
weight is put on the number of selectors matched. More matching
selectors means more weight.

If extensions and selectors match, the most specific resource type wins.

In this situations we have:

  (1) request methods are the same -- GET -- tie
  (2) request extension matches for Servlet B, Servlet A has no specific
         request extension.

Tie resolved, Servlet B wins for more specific request extension.

This has always been like this and it always worked perfectly.

As I said, this is comparable to Java object hierarchies and method
overloading and extension. In this respect Servlet B has to "win", too,
since it has a more specific method to handle the request, even though
the type is less specific. But this works as designed and desired.

Regards
Felix


> 
> Justin
> 

Re: Extensions more important than resource type in servlet resolution?

[Justin Edelson <ju...@gmail.com>]

On 5/17/10 8:19 AM, Alexander Klimetschek wrote:
> On Mon, May 17, 2010 at 13:55, Felix Meschberger <fm...@gmail.com> wrote:
>> The observed behaviour is correct, because the more details of a request
>> match what the registered servlet supports, the more weight the servlet
>> becomes.
>>
>> Thus in the Servlet A case, only the method name matches, while in the
>> Servlet B case the method (implicitly GET) and the request extension
>> match. Thus Servlet B must be selected even though it is defined higher
>> up in the resource type hierarchy.
>>
>> Compare this to Java where also the best matching method is slected from
>> the class hierarchy regardless of where in the hierarchy the method placed.
> 
> After a chat with Felix we came to the conclusion that this is an
> unfortunate specific case, where it seems wrong, but can't be seen as
> a bug in Sling.
> 
> The problem is amplified by:
> - servlet B being registered for the default resource type (which is
> always dangerous and must be done with care)
> - servlet A not being registered for extensions
> 
> The solution in this case is to do the latter, and either try to
> register servlet B for specific resource types, if possible, or make
> the accepts() method handling more specific (which works based on
> paths in this case and is the simplest solution here).
> 
> Conclusion: watch your default servlet registrations. Specific
> resource type scrips without extensions/selectors loose against
> default servlets with specific extensions/selectors!
> 
> Regards,
> Alex
> 
Hmmm. I'm not convinced this isn't a bug. Both Servlet A and Servlet B
match two criteria (resource type and method in the case of Servlet A
and extension and method in the case of Servlet B). In the case of a
"tie" like this, shouldn't we put more weight behind the resource type?

Justin