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
[EMAIL PROTECTED]

Reply via email to