struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@apache.org>
Subject Re: Reasons for 1.3 release
Date Fri, 17 Feb 2006 05:59:26 GMT
On 2/16/06, Frank W. Zammetti <fzlists@omnytex.com> wrote:
>
> Martin Cooper wrote:
> > Yes, I'm modifying the RP chain in both my 1.3 and 1.2+chain apps,
> primarily
> > for stuff that needs to be centralised, such as authorisation, error /
> > exception handling, and some specialised cancellation handling.
>
> This part is especially interesting because it leads me to a question
> that may come up as CoR becomes more well-known in Struts land... why is
> a composable RP better than a collection of filters?


It is a little simpler to use than filters (the programming interface for a
command is a *lot* simpler than for a Filter), and a bit easier to configure
as well.  But the primary reason for a CoR based request processor (RP) is
to get rid of the restrictions of an RP implemented as a single class, where
the mechanism for specialization is a subclass.  Java's single inheritance
makes it really difficult to combine more than one specialized subclass of
RequestProcessor into a single app.

  It's essentially
> the same thing, except that you could probably say you have more control
> over your own chain.  Why would something like security for instance be
> better implemented as a modified RP chain than some loosely-coupled
> filters?  I ask this partly because we have a complex security framework
> at work that takes the filter approach, although it could just as easily
> be done in the app framework itself.  Any thoughts?


If you already grok filters, go for it.  But I can see a day coming where
even more people are going to bitch about having to edit web.xml files to
set up all the filter mappings :-).

Frank


Craig

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message