Hi Mike, Mike Müller schrieb: > That seems to be exactly what I'm searching for. Thank you very much, > also for the docu page on the Sling site itself. > I was a little bit confused concerning the Filter implementation because > of the thread [1] on the list a year ago...
That was something slightly different: The use case was to be able to work around a limitation of the resource resolver at that time (virtual host support). The proposal was to register a regular servlet filter, which would of course only have worked with sling running as a web application. > > BTW there's a little mistake on the docu on top, instead of > javax.servlet.Filter > you wrote javax.jcr.Filter. Thanks for reporting. If just fixed this. Regards Felix > > [1] http://markmail.org/message/okmvvgs5ff64i3xa > > best regards > mike > >>>>> ... snip snap ... >>> What I try tio achieve is run some legacy stuff shoulder to >> shoulder with >>> new stuff which entirely is built on Sling. So the >> MyServlet (or call it >>> LegacyServlet) should check (as OptingServlet) if the >> request is a call >>> to the legacy stuff and handle it in this case. If not, >> accepts() on the >>> LegacyServlet should return false and the request should be >> handled by the >>> default Servlets of Sling (or any other registered Servlet >> for the request). >> >> Ok, the crucial point here is "any other registered Servlet": If Sling >> decides to no check for another servlet, your LegacyServlet will never >> be asked whether it accepts the request or not. >> >>> So plugging in the functionality to the existing >> DefaultGetServlet and the >>> SlingPostServlet is probably not the solution. >> Agreed, but mainly due to how servlet resolution works. >> >>> Extending from the existing default Servlets seems to fit >> better in this case. >>> Maybe also Filters could help in this case, but as far as I >> understood filters >>> are not preprocessed in a Sling standalone app, so the >> solution with filters >>> would be bound to using Sling in a Servlet container (which >> I do not prefer!). >> >> Filter processing inside Sling is always the same because Sling is >> managing the filters themselves and does not work with the servlet >> container filter processing. As such Filters registered as Filter >> services in Sling always work the same, no matter what. >> >> So for your legacy issue, I would suggest you create a request filter >> (filter.scope="request") which checks whether the request is for a >> legacy resource or a sling resource. >> >> If the request is for a legacy resource, the filter processes the >> request in the legacy way and terminates the request after that by >> simply not calling the FilterChain.doFilter method. >> >> If the request for a Sling resource (non-legacy), the request >> is simply >> passed through to the filter chain calling FilterChain.doFilter. >> >> Would that work for you ? >> >> Regards >> Felix >> >> PS: I have just written down some more information on filters which >> should appear on the site in an hour or two, until then the page may >> already be seen at http://cwiki.apache.org/SLINGxSITE/filters.html >> >> >
