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

-- 
Alexander Klimetschek
[email protected]

Reply via email to