struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Seekamp <>
Subject Re: Multiple RequestProcessors
Date Tue, 27 Aug 2002 17:45:26 GMT


OK, thanks very much.  A couple of other hopefully minor issues. I didn't
notice changes to existing files under the contrib folder samples that I
looked at.  So is it a problem to put a modified version of ActionServlet.
java for instance under the contrib folder? I could theoretically subclass
that one, but coming up with a subclass of for the
one change I need to make in it would not be of much use unless we wanted
to make other otherwise unnecessary changes to reference it instead of
ControllerConfig.  So is putting modified versions of existing files under
the config folder allowed?  How do people play with what is in the contrib
folder anyway?  Can they be expected to overwrite some base files and

One other basic question: the files should not have expanded keywords.
That is I should just have "$Header$" rather than "$Header:
/home/cvspublic..." right?  I guess some committer would at some point take
the zip and put the files into CVS?


Chris Seekamp

"Craig R. McClanahan" <> wrote:

On Tue, 27 Aug 2002, Christopher Seekamp wrote:

> Date: Tue, 27 Aug 2002 12:52:55 -0400
> From: Christopher Seekamp <>
> Reply-To: Struts Developers List <>
> To: Struts Developers List <>
> Subject: Re: Multiple RequestProcessors
> Craig:
> That sounds reasonable to me.  I have no problem adding what we have to
> contrib folder.  From looking around at the doc on submitting patches
> I only understand how you submit a patch for an existing file.  I don't
> want to trouble you for a lot of details, so can you point me to
> that explains how you submit a patch that contains new folders
> (directories) and new files.  I guess I can't use diff for new files and
> folders.

Sorry for the lack of docco on this.  The simplest way for an initial
hierarchy like this would be to submit a zip file that contains the entire
new set of files, with a note that says something like "please unzip these
files into a new "contrib/foo" directory in the CVS server.  You could put
this in as an enhancement request in Bugzilla
<> with a file attachment.

After the initial checkin, patches would work like they do for any other
existing file.

> Thanks.
> Chris Seekamp


> Hi Chris,
> Thanks for the thoughtful analysis on this topic!  Refactoring
> RequestProcessor in a manner that lets you combine customizations (like
> your suggestion to use a decorator pattern) is high on my list of things
> to look at for a post-1.1 release of Struts.  I don't know of anyone who
> has proposed a comprehensive suggested design for this yet (and I've
> purposely avoided starting the design discussions lest they distract us
> from getting 1.1 out the door ... :-).
> In the mean time, it would definitely be worth exploring whether we could
> create a DecoratableRequestProcessor (or whatever we want to call it) as
> an optional replacement for the current one, implementing your decorators
> or chaining inside that implementation -- so that ActionServlet doesn't
> know anything special is going on.  We could perhaps store the
> experimental implementation in the "contrib" directory so that people
> could try it out.  We could use the results to influence the final design
> of the "real" request processor for Struts post-1.1.
> Does that sound like a viable plan?
> Craig
> On Mon, 26 Aug 2002, Chris Seekamp wrote:
> > Date: Mon, 26 Aug 2002 16:55:58 -0400
> > From: Chris Seekamp <>
> > Reply-To: Struts Developers List <>
> > To:
> > Subject: Multiple RequestProcessors
> >
> > Although the change in Struts 1.1 to implement the RequestProcessor
> > was a great improvement over having to extend the ActionServlet,
> > as has been pointed out before, there can be issues when multiple
> > people want to extend the RequestProcessor. For instance, my group
> > extended the RequestProcessor so Struts would work well in our
> > particular environment.  Suppose we or our users want to utilize Tiles,
> > which has some really great capabilities?  Well, if we could extend the
> > Tiles RequestProcessor we would now need another version of our
> > RequestProcessor that extended the Tiles RequestProcessor rather than
> > the base RequestProcessor. But in our case, we override doForward too
> > (like Tiles does) and we would actually need Tiles to sit on top of
> > (subclass) our RequestProcessor rather than the other way around. So we
> > would have to take the Tiles source and generate another subclass of
> > the TilesRequestProcessor that extended our RequestProcessor rather
> > than the plain RequestProcessor.
> >
> > And as more and more extensions become available, ideally we would like
> > to be able to choose various combinations of extensions to use.  Of
> > course, using subclassing this becomes rather problematic for obvious
> > reasons. If there are 3 different extensions you want to build upon, if
> > you are lucky you could just create three different versions of your
> > own RequestProcessor subclassing each of the those 3 separately.  Of
> > course, if you want to build on two at the same time..... Well, you get
> > the idea.
> >
> > So, we, and we expect others, would like to improve the chances that
> > our various extensions can be used together.  We have implemented an
> > approach based on the Decorator (Wrapper) pattern that allows
> > processors to be chained together.  If you choose not to subclass from
> > this wrapper class things are the same.  But if you make your
> > RequestProcessor subclass from the wrapper and follow some simple
> > steps, you can be part of an ordered chain of RequestProcessor
> > instances.  In addition to adding the wrapper, we had to make small
> > changes to ActionServlet in getRequestProcessor (to build the chain the
> > first time it is called) and the RequestProcessor itself to call the
> > top (last) processor's methods and ControllerConfig to keep the
> > chain of classes. Besides subclassing the wrapper class
> > rather than the RequestProcessor, the only new things processors need
> > to worry about is making sure to all the subclass version of the method
> > they are extending and to call the top processors version's of other
> > processor methods they call.  For example, if you have your own
> > processActionForward method you should remember to
> > call super.processActionForward.  You normally would want to do this
> > anyway.  Continuing the example if processActionForward wants to call
> > doForward, it should call the top processors doForward instead because
> > it might not be the top (last) processor in the chain.
> >
> > We know others have brought up the problem of multiple
> > RequestProcessors before.  We would be happy to donate our approach as
> > a starting point, because we would like different extensions that
> > require extensions to RequestProcessor to be usable together as much as
> > possible without having to compile numerous different versions.  For
> > example, using the straight inheritance approach we would have to be
> > prepared to generate a new version of the Tiles RequestProcessor
> > extending our RequestProcessor every time there was a change made in
> > the Tiles RequestProcessor.  So maybe there are some far-reaching plans
> > to address this issue in Struts or maybe someone else is already
> > working on a different solution?
> >
> > If not,  is there any interest in discussing extending the
> > RequestProcessor support to support some kind of chaining approach? I
> > would be happy to give more details on what we have come up with.  I
> > haven't submitted any patches yet, but I assume this is not the kind of
> > thing one should simply submit as a patch anyway, at least not without
> > discussing the appropriateness of the approach first.
> >
> > Thanks and sorry for the long post.
> >
> > Chris Seekamp
> >
> >
> >
> > --
> > To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache
> org>
> > For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache
> org>
> >
> >
> --
> To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.
> >
> For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.
> >
> --
> To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.
> For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.

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

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

View raw message