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