Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of craigmcc@gmail.com designates
 64.233.162.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references;
        b=Wo4TQ48axqoNHsdVRyzhTIyk9SmpP8Jr3tJPIRd2dATJRVb5XEIvWnPZV3rA6Y4lMO56eqfqdLH646BCV2EoselgOgIlYA1PTbeKfwy+L+0pgQuWggTXG9U6N9VSjPJFBxwgTnV9OAef7KwDRgj1qcL/HXo+jDkKfwLFCxyYbiI=
Message-ID: <f8b39ace0602162159o6574081ap18de02f76cc18a0f@mail.gmail.com>
Date: Thu, 16 Feb 2006 21:59:26 -0800
From: Craig McClanahan <craigmcc@apache.org>
Sender: craigmcc@gmail.com
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: Reasons for 1.3 release
In-Reply-To: <43F55C15.2050100@omnytex.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_8070_11494430.1140155966786"
References: <1db115340602160939p2a5106a1m8066656906cac711@mail.gmail.com>
	 <61931.170.201.180.136.1140111783.squirrel@webmail.chiron.lunarpages.com>
	 <1c661f2f0602160949n6274dbdfy406a43a77b8f57a3@mail.gmail.com>
	 <1db115340602161218v57e048b8ma90bb90befc37239@mail.gmail.com>
	 <16d6c6200602161252s59025139i6ae0a4fa30208994@mail.gmail.com>
	 <1db115340602161304m4f6d09ccs2736ae1254263f5@mail.gmail.com>
	 <16d6c6200602161320t9cbc708j442cb4a89abf27c9@mail.gmail.com>
	 <23679.170.201.180.136.1140125248.squirrel@webmail.chiron.lunarpages.com>
	 <16d6c6200602161435w5c678b36td97c941399fc0d34@mail.gmail.com>
	 <43F55C15.2050100@omnytex.com>

------=_Part_8070_11494430.1140155966786
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 configur=
e
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, wher=
e
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

------=_Part_8070_11494430.1140155966786--