On 2/16/06, Frank W. Zammetti <[EMAIL PROTECTED]> 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
