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 <[email protected]> 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
>
