If we were to build everything on such a structure, configuring a Struts app would be mostly done by letting Struts load its standard definitions of all the chains (from some internal-to-Struts XML resource), then letting the application load its own config files -- possibly overriding the standard chain definitions -- then specifying the name of the chain that initially gets control (and is therefore responsible for processing the entire request). There wouldn't really be a RequestProcessor any more (although for 1.1 we'd probably implement all this inside a new one that simply replaces the process() method with the appropriate chain lookup and execution.)
Regarding the 1.1 request processor, do you envision the process() method just reading the XML file and calling execute() on a chain, or would you expect to have several predefined chains that process() would execute and application developers could extend? From your notes above, it looks like the process() method would just execute one or more chains. Peter's code in this thread sort of looked like it would invoke each processX() method as a separate chain.
I guess the question is "How composable should it be?" Obviously, there are some things that *have* to be done for it to really be a Struts request processor, right? We may not want applications to be able to compose those things out. And, as you mentioned earlier, order is definitely important.
Greg
DISCLAIMER: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
