struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Bauer <>
Subject Re: composable RequestProcessor
Date Mon, 02 Jun 2003 09:00:59 GMT
I will try to wrap up, what we are up against: The current 
RequestProcessor implementation does not support chains of request 
processors. So the developer has to decide which request processor to 
choose. This brings him into a dilemma, if he wants to use two struts 
extensions that both implement their own request processor, e. g. 
ExtOneRequestProcessor and ExtTwoRequestProcessor. Only if one of the 
two extensions provides a ExtOneExtTwoRequestProcessor that  integrates 
the functionality of both of them, the two extensions can be used together.

For two extensions being around this can be accomplished. But as soon as 
the number of extensions grows beyond 2 (which has already happened) 
this is fairly impossible. Providing a RequestProcessor interface does 
not really relieve the situation. Even though it will  make it easier to 
compose a request processor from other request processors, a subclass 
for each possible combination of request processors must be implemented.

Thus, by now I believe the request processor architecture should be 
changed more fundamentally to allow a more selective change of 
functionality. Maybe they should be working more like servlet filters, 
so they can be chained?

Any thoughts?

--- Matthias

Peter A. Pilgrim wrote:

> Joe Germuska wrote:
>> At 16:33 +0100 6/1/03, Peter A. Pilgrim wrote:
>>> For Expresso I too have subclassed the TilesRequestProcessor
>>> for our own ExpressoRequestProcessor. Can a module have
>>> more than one controller?
>> Not the way it is right now, and I'm not sure why you'd need it.  I 
>> think if you want to use the approach you described:
>>> <manager class="ControllerManager" >
>>>   <controller class="TilesRequestProcessor" />
>>>   <controller class="FoobarRequestProcessor" />
>>>   <controller class="AcmeRequestProcessor" />
>>> </manager>
>> ... then it makes more sense to define interfaces for each lifecycle 
>> method of RequestProcessor and use the XML to configure a collection 
>> of handlers.  But David, at least, seems to think that's overkill.  I 
>> don't feel very strongly about it, but no one else has even weighed 
>> in.  It would mean a lot of interfaces, given that RequestProcessor 
>> has 16 "process*" methods.  Probably it is overkill...
>> Given the XML you provided, how would the Manager know which 
>> controller to use when?
> Ah ha! I thought you saying something different. Before I thought
> ComposableRequestProcessor is not a RequestProcessor.
> But you are saying that is. That is why my example XML is nonsense.
> You cannot chain request processors from one to another,
> because they were not design that way. I agree which process
> method do you call?
> Let's take a back step, then. What is a composable request processor?
> What is the thing that you are trying to build?
> MasterRequestProcessor master = new MasterRequestProcessor();
> master.add( TilesRequestProcessor );
> master.add( FoobarRquestProcessor );
> Is this it?
> Another question what is it that the different request processors
> are override or overloading? For the Tiles controller it is the
> init(), doForward(), processForwardConfig(),
> internalModuleRelativeForward(), internalModuleRelativeInclude() ?
> For Expresso controller we override
> init(), processPreprocesss(), createAction()
> There is a no common method here in these two controllers.
> We cannot isolate a method that would make up a composable
> request processor.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message