Thanks for the test cases Ted! More comments below...Of course I am :-). After all, I'm loading the configuration for a "request processor" that has to tie in to the rest of the Struts infrastructure, so I know that it's all going to be there.
----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
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.
That particular issue can be addressed with a temporary workaround for 1.1.RequestProcessor
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
class to assemble the request processing pipeline:Also in the Struts Contrib CVS is a PlugIn class. Problem is, other
contrib/struts-chain/src/conf/chain-config.xml
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).
Once ChainServlet has assembled the Catalog, how are you planning to make it available to the rest of the application? Storing it as a servet context attribute still ties you to the servlet API, and that's (IMHO) too restrictive for a configuration mechanism inside commons-chain itself, which should be perfectly usable in a non-web environment.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.
This is the kind of reason why I stopped at providing you environment-independent APIs (and even using Digester to read XML files is an option -- you're perfectly free to configure the Catalog in other ways as well) to assemble your own configuration loading; tying it in to the rest of the "container" or "environment" you are running in should be the business of the client application, not the commons-chain package itself.
Craig
-Ted.
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
