commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sgarlata Matt" <sgarlata_m...@bah.com>
Subject Re: [Chain] examples XML file available?
Date Tue, 23 Sep 2003 01:22:46 GMT
Thanks for the test cases Ted!  More comments below...
----- Original Message ----- 
From: "Ted Husted" <husted@apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Sunday, September 21, 2003 10:32 PM
Subject: Re: [Chain] examples XML file available?


>  > If I play with the package some more and like it, I could provide a
>  > DTD for the XML file and documentation for it.  That should save Craig
>  > and Ted from some boring work :)
>
> What might be helpful is a standalone ChainServlet that would load the
> configuration file, like the sample PlugIn does. (A HiveMind service
> might also be very cool.)

I can write the ChainServlet this week, borrowing relevant code from the
CatalogConfiguratorPlugIn :)  HiveMind looks cool, but I'm not ready to
invest time in learning it yet.

> Right now, I'm loading it as a Struts PlugIn (and imagine Craig is too),
> but that wouldn't work for everyone.
>
>
> Craig R. McClanahan wrote:
> > There's another example in the CVS HEAD sources of Struts, where we are
> > experimenting with building a replacement for the current
RequestProcessor
> > class to assemble the request processing pipeline:
> >
> >   contrib/struts-chain/src/conf/chain-config.xml
>
> Also in the Struts Contrib CVS is a PlugIn class. Problem is, other
> parts of that distribution are coupled to the Struts Nightly Build and
> won't compile under Struts 1.1 (namely the Constants.MODULE_CONFIG_KEY).
>
> I'd like to move the Struts CatalogConfiguratorPlugIn to the Commons
> Chain distro and make it an optional compile, like JSF et al. That way,
> people could start using Chain with Struts 1.1 "out of the box".
>
> Even if we could decouple the Contrib package from the Nightly Build,
> I'm thinking if we have these other optional packages here, we can also
> have one for Struts. So, the ComposableRequestProcessor would stay
> there, but the CatalogConfiguratorPlugIn would move here.
>
> Does this sound all right?

Actually, if we write a ChainServlet then do we need a Struts PlugIn at all?
If the ChainServlet is set to load before the ActionServlet and the
ChainServlet stores its catalog in a known location, Struts users should be
able to use the ChainServlet without using a PlugIn at all.  I do agree with
your reasoning that the CatalogConfiguratorPlugIn should live in Chain
instead of Struts, but I don't see a need for a PlugIn at all.

> -Ted.

Matt


Mime
View raw message