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.
Right now, the Commands I have in place are quite simple and don't need to refer back to the Catalog. (Just simple calls to a DAO layer designed to that share the same Context.) So, I just bootstrap the call from the presentation layer controller (e.g. Action class). The chain I'm calling is passed up from the configuration file, so I can use the same base class for most everything. [Which might sound familiar :0)]
When things become more complex, I'm thinking that a reference to the Catalog (or Catalogs) can be stored in the Context, along with everything else. So the presentation layer factory (or independent test case) can include a reference to the Catalog when it assembles the rest of the Context. If a Command needs a reference to the Catalog, it can get it from the Context. The Catalog may be stored in the servlet context, but the Command doesn't need to know that.
Some applications could devolve to a Context that executes itself by checking for a Command name under a default attribute and then executing that Command using a Catalog stored under another default attribute.
Of course, another way to go would be to make the Catalog a singleton, or available through some registry, but I'm thinking that going through the Context may be the cleanest approach, since the Context is essentially a Registry too.
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.
Agreed. But if we are offering standard optional packages for JavaServer Faces, Servlets, and Portlets, it seems like we can do the same for Struts too. If the Struts JAR isn't there, the plugin package wouldn't be compiled. In this way, Struts 1.1 people can start using the package right away, without having to get the Struts contrib as well. And if someone contributed a standard servlet implementation, then Struts 1.0 people, as well as most anyone else, could also start using it "out of the box".
-Ted
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
