Handling multiple servlets for a resource type?

[Carsten Ziegeler <cz...@apache.org>]

I'm wondering if we do something about the case where more than one
servlet is able to process a specific resource type?
For example, you have a bundle containing "standard" servlets for some
resource types providing a default rendering.
Then you want to provider for one of the resource types a different
servlet for rendering. Now, you put your new rendering servlet into your
bundle and end up with two servlets (from different bundles) for a
resource type.
Of course you can't disable the whole "standard" bundle as you want to
use the other servlets for the other resource types.

You could disable the single servlet through the admin console, but
that's not really nice.

It would be good to have some mechanism which allows me to just deploy
my bundle with my new servlet and this one is always picked up - without
any further configuration. Perhaps this could be done with an "order"
property?

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Handling multiple servlets for a resource type?

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

Hi,

Am Donnerstag, den 20.12.2007, 12:26 +0100 schrieb Carsten Ziegeler: 
> > I think, if we emply these finegrained controls for servlet selection we
> > also have not much pressure in providing such a priorization scheme,
> > which looks somewhat shaky. In fact using fine grained control, we can
> > have servlets which just render resources for GET requests and leave
> > handling resource updates to the default servlet.
> > 
> I agree that it makes sense to use the same mechanism for servlet
> resolving as we are using for script resolving. And I also agree that in
> most cases only the GET case is handle by the servlet.
> 
> But :) the question remains if we want to provide/think about a
> mechanism to handle the situation where two servlets would handle the
> same request. Or the case where a servlet and a script would handle the
> same request. Or even two scripts.
> 
> Perhaps this is currently a more theoretical discussion, but imagine you
> use some bundles providing default behaviour for your content and you
> want to specialize this default behaviour, like using inheritance in OO
> languages?
> It is possible to leave this up to the administrator as he can activate
> or deactivate services - but again this doesn't seem to be very user
> (developer) friendly.

For script resolution we have the path concept: if a script path
consisting of the resource type, the selector(s) and the request method
or extension is relative, a prefix (/libs and /apps by default) is
applied and the first script found wins.

For servlets we might apply the same logics: If a "path" is relative a
list of prefixes is applied in succession until a servlet is found.

The only difference is, that in the repository only a single script with
a given path may exist while for servlets multiple servlets with the
same path may exist. I think, we need not over-react to such a potential
collision at the moment, provided we introduce such a absolute/relative
path concept.

Regards
Felix

Re: Handling multiple servlets for a resource type?

[Carsten Ziegeler <cz...@apache.org>]

Felix Meschberger wrote:
> Hi,
> 
> Am Donnerstag, den 20.12.2007, 11:39 +0100 schrieb Carsten Ziegeler:
>> I'm wondering if we do something about the case where more than one
>> servlet is able to process a specific resource type?
>> For example, you have a bundle containing "standard" servlets for some
>> resource types providing a default rendering.
>> Then you want to provider for one of the resource types a different
>> servlet for rendering. Now, you put your new rendering servlet into your
>> bundle and end up with two servlets (from different bundles) for a
>> resource type.
>> Of course you can't disable the whole "standard" bundle as you want to
>> use the other servlets for the other resource types.
> 
> Basically, I have some doubt, whether it is a good idea to have support
> for the same resource type in different bundles: But....
> 
> We need more fine grained control of when a servlet is selected to
> handle a request for a resource. My idea is, that we apply the same
> mechanics for servlet selection as we apply for script selection: Not
> only take the resource type into account but also the request method,
> selectors and request extension.
> 
> I think, if we emply these finegrained controls for servlet selection we
> also have not much pressure in providing such a priorization scheme,
> which looks somewhat shaky. In fact using fine grained control, we can
> have servlets which just render resources for GET requests and leave
> handling resource updates to the default servlet.
> 
I agree that it makes sense to use the same mechanism for servlet
resolving as we are using for script resolving. And I also agree that in
most cases only the GET case is handle by the servlet.

But :) the question remains if we want to provide/think about a
mechanism to handle the situation where two servlets would handle the
same request. Or the case where a servlet and a script would handle the
same request. Or even two scripts.

Perhaps this is currently a more theoretical discussion, but imagine you
use some bundles providing default behaviour for your content and you
want to specialize this default behaviour, like using inheritance in OO
languages?
It is possible to leave this up to the administrator as he can activate
or deactivate services - but again this doesn't seem to be very user
(developer) friendly.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Handling multiple servlets for a resource type?

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

Hi,

Am Donnerstag, den 20.12.2007, 11:39 +0100 schrieb Carsten Ziegeler:
> I'm wondering if we do something about the case where more than one
> servlet is able to process a specific resource type?
> For example, you have a bundle containing "standard" servlets for some
> resource types providing a default rendering.
> Then you want to provider for one of the resource types a different
> servlet for rendering. Now, you put your new rendering servlet into your
> bundle and end up with two servlets (from different bundles) for a
> resource type.
> Of course you can't disable the whole "standard" bundle as you want to
> use the other servlets for the other resource types.

Basically, I have some doubt, whether it is a good idea to have support
for the same resource type in different bundles: But....

We need more fine grained control of when a servlet is selected to
handle a request for a resource. My idea is, that we apply the same
mechanics for servlet selection as we apply for script selection: Not
only take the resource type into account but also the request method,
selectors and request extension.

I think, if we emply these finegrained controls for servlet selection we
also have not much pressure in providing such a priorization scheme,
which looks somewhat shaky. In fact using fine grained control, we can
have servlets which just render resources for GET requests and leave
handling resource updates to the default servlet.

WDYT ?

Regards
Felix