multiple Servlets registered for resourceTypes sling/servlet/default

[Mike Müller <mi...@mysign.ch>]

Hi

If you register an own Servlet which should be used as default servlet you can register it with

sling.servlet.resourceTypes=sling/servlet/default
sling.servlet.methods=GET
(if it should work only for GET requests)

If I upload a bundle with such a Servlet (call it MyServlet) in Sling everything seems to be fine, the GET requests are dispatched by the MyServlet. But after a restart of Sling it's a random luck which Servlet (the DefaultGetServlet or the MyServlet) will dispatch the request. Shouldn't there be a way to mark a Servlet as the one with higher priority. There is the getWeightedResources method on the ResourceCollector, but this doesn't help, because neither Servlet has more "weight". In my case I would like to install a Servlet which implements the OptingServlet and gets all requests first to decide if the DefaultGetServlet should handle the request or if it should be handled by the MyServlet itself.

best regards
mike

Re: AW: multiple Servlets registered for resourceTypes sling/servlet/default

[Felix Meschberger <fm...@gmail.com>]

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

AW: multiple Servlets registered for resourceTypes sling/servlet/default

[Mike Müller <mi...@mysign.ch>]

Hi Felix

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

BTW there's a little mistake on the docu on top, instead of javax.servlet.Filter
you wrote javax.jcr.Filter.

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

Re: AW: multiple Servlets registered for resourceTypes sling/servlet/default

[Felix Meschberger <fm...@gmail.com>]

Hi Mike,

Mike Müller schrieb:
>>> ... 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

AW: multiple Servlets registered for resourceTypes sling/servlet/default

[Mike Müller <mi...@mysign.ch>]

> > If you register an own Servlet which should be used as
> default servlet you can register it with
> >
> > sling.servlet.resourceTypes=sling/servlet/default
> > sling.servlet.methods=GET
> > (if it should work only for GET requests)
> >
> > If I upload a bundle with such a Servlet (call it
> > MyServlet) in Sling everything seems to be fine, the GET
> > requests are dispatched by the MyServlet. But after a restart
> > of Sling it's a random luck which Servlet (the
> > DefaultGetServlet or the MyServlet) will dispatch the
> > request. Shouldn't there be a way to mark a Servlet as the
> > one with higher priority. There is the getWeightedResources
> > method on the ResourceCollector, but this doesn't help,
> > because neither Servlet has more "weight". In my case I would
> > like to install a Servlet which implements the OptingServlet
> > and gets all requests first to decide if the
> > DefaultGetServlet should handle the request or if it should
> > be handled by the MyServlet itself.
>
> Frankly, this ain't gonna work: you cannot reliably register two
> servlets with the same setup. For this reason you can only replace the
> DefaultGetServlet by removing the o.a.sling.serlvets.get bundle.
>
> I presume, that this is not an option, though ;-)
>
> Now my question is: what functionality do you implement in
> your special
> generic GET servlet, which is missing from the Sling
> DefaultGetServlet.
> Could there be a chance of plugging your required
> functionality into the
> DefaultGetServlet ?
>
> Another option would be that you create your own servlet
> extending from
> the DefaultGetServlet. You then create a bundle with your own code
> merged with the contents of the o.a.sling.servlets.get bundle and only
> install your own bundle. But I suggest, we first explore the
> first option.

Hi Felix

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).
So plugging in the functionality to the existing DefaultGetServlet and the
SlingPostServlet is probably not the solution.
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!).

is there any other possability?

best regards
mike

Re: multiple Servlets registered for resourceTypes sling/servlet/default

[Felix Meschberger <fm...@gmail.com>]

Hi Mike,

Mike Müller schrieb:
> Hi
> 
> If you register an own Servlet which should be used as default servlet you can register it with
> 
> sling.servlet.resourceTypes=sling/servlet/default
> sling.servlet.methods=GET
> (if it should work only for GET requests)
> 
> If I upload a bundle with such a Servlet (call it MyServlet) in Sling everything seems to be fine, the GET requests are dispatched by the MyServlet. But after a restart of Sling it's a random luck which Servlet (the DefaultGetServlet or the MyServlet) will dispatch the request. Shouldn't there be a way to mark a Servlet as the one with higher priority. There is the getWeightedResources method on the ResourceCollector, but this doesn't help, because neither Servlet has more "weight". In my case I would like to install a Servlet which implements the OptingServlet and gets all requests first to decide if the DefaultGetServlet should handle the request or if it should be handled by the MyServlet itself.

Frankly, this ain't gonna work: you cannot reliably register two
servlets with the same setup. For this reason you can only replace the
DefaultGetServlet by removing the o.a.sling.serlvets.get bundle.

I presume, that this is not an option, though ;-)

Now my question is: what functionality do you implement in your special
generic GET servlet, which is missing from the Sling DefaultGetServlet.
Could there be a chance of plugging your required functionality into the
DefaultGetServlet ?

Another option would be that you create your own servlet extending from
the DefaultGetServlet. You then create a bundle with your own code
merged with the contents of the o.a.sling.servlets.get bundle and only
install your own bundle. But I suggest, we first explore the first option.

Regards
Felix