Sorry for the late response on this ... it seems like weekends are the
only time I get to play with open source code any more :-(.
See interspersed comments below.
On Tue, 19 Aug 2003, Greg Reddin wrote:
> Date: Tue, 19 Aug 2003 07:28:53 -0500
> From: Greg Reddin <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Struts Composable Request Process (was RE: ActionForwards,
> et al)]
>
> Just to play around with this idea, I've attached my initial hack at a
> 1.x-compatible composable request processor using struts-chain. Let me
> know if this is anywhere near the mark for a 1.x request processor.
>
Thanks for this! I've committed it with only one significant change -- I
split off the configuration stuff into a separate PlugIn class that can be
used to load one or more configuration resources into the catalog (which
is then exposed as a servlet context attribute. An example of this will
be the following plug-in configuration to load the standard chain
definitions:
<plug-in
className="org.apache.struts.chain.legacy.CatalogConfiguratorPlugIn">
<set-property name="resource"
value="/org/apache/struts/chain/chain-config.xml"/>
</plug-in>
I'm going to be working towards getting the Struts example app running
with the ComposableRequestProcessor implementation as a proof of concept.
> Here's a few notes/questions:
> 1) It does not do the "servlet-complete" chain b/c in 1.x the module is
> already selected by the time the request processor is executed as far as
> I can tell.
>
That's right. You would use "servlet-complete" only in a replacement for
ActionServlet, instead of a replacement for a module-specific request
processor.
> 2) The XML config file is hard-coded into the initialize method. I
> assume we'd want that to be more configurable.
>
I split this out, as described above. It's set up so you can load as many
config resources as you want -- the last definition for any particular
chain id wins.
> 3) The "servlet-standard" chain is executed in the process() method. I
> also assume we'd want that to be configurable.
Agreed. It's still not configurable now, but we'd want it to be.
>
> 4) I wasn't sure if any synchronization needed to occur around the
> creation/destroying of the catalog, so I left it out.
>
You shouldn't need this, because the init() and destroy() methods of a
RequestProcessor (and a PlugIn) are executed only in a single thread.
> 5) If an exception occurs in the process() method, we may want to call
> a processException chain or something more flexible than how I handled it.
One of the tasks on my list is to create a new Command that is really a
Filter (see commons-chain), and stick that early in the processing chain
to do the exception handling stuff we do today in processException().
This allows any subsequent Command (not just the one that executes the
selected Action) to throw an Exception, and have it handled through the
standard machinery.
We still need an outer try/catch block like the one you wrote, but if it
actually gets fired then somebody didn't configure exception handling into
their chain correctly.
>
> To make it go I added this class and the struts-chain code to the source
> tree and the commons-chain.jar to the build script. I then added the
> chain-config.xml file to my WEB-INF directory and it worked -- at least
> for the simple case of executing an action.
Cool. I'm going to do the stuff that processes the ActionForward that is
returned next, and then try to get the struts-example webapp running.
> Next, I'm going to see
> about integrating Tiles and extending the chain. I would appreciate
> feedback on this. We've come up with several places where this could be
> very useful, so I'm probably going to be working on something like it
> whether it ends up in Struts 1.x or not.
>
Glad to see that you're interested. Please keep offering suggestions and
patches, and I'll try to get them into the contrib directory.
> Greg
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
