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