Hi Felix! On Wed, Feb 11, 2009 at 6:45 PM, Felix Meschberger <[email protected]> wrote: > Well, the mention of the NonExistingResource may be the key in your use > case: Since NonExistingResources have their own resource type > (sling:nonexisting IIRC), you may register a servlet for that resource > type and act upon it as desired. If you don't want to handle the > concrete request for any one reason, you can -- as a servlet -- > implement the OptingServlet interface and return false on the respective > method.
Ah, that concept totally makes sense. Didn't thought so far ;-) This probably means I would need two different servlets if I want to handle both requests to non-existing resources and to existing ones, where the servlet would "update" an existing import. With the scr javadoc annotations, one can only register the servlet for one resource type / selector combination at a time, right? (eg. 1) resource type = "sling:nonexisting", selector = "i18n" and 2) resource type = "i18n/dictionary" in my example). > I am not a big fan of extending or changing the servlet resolution just > for this. > > What we might do is provide some plugin functionality based on the > sling:nonexisting resource type, where one might register its interest > in handling requests to such resources. The sling:nonexisting mechanism makes sense for that case, so we don't have to change the servlet resolution. The only thing that might be needed is registering a single servlet for multiple resources/paths/selectors etc. Is that possible? Regards, Alex -- Alexander Klimetschek [email protected]
