I'm not keen on adding init params in general, and even less keen on adding such params that take lists of files.
I do think we need to have a mechanism for specifying global stuff, but I think we can come up with a better way. For example, I don't like that I have to replicate the <controller> config in each module's struts-config.xml in a multi-module app. That's error prone.
We've talked about allowing for <extend> for things like form bean definitions. What about having this concept right at the top of the config scheme? So I could define a global struts-config.xml file (which wouldn't be used directly by any module), and then <extend> that file to provide module-specific config files.
If we added an optional section to struts-config, we could then specify a list of Chain config files in there.
I can go along with hesitance to use Servlet init params -- perhaps because we're trying to limit dependencies on the Servlet API? But there is nothing more global than the ActionServlet right now, and no way to configure anything at that level (at least, that I can think of off the top of my head.)
We could certainly leave the plugin in place as a way to bootstrap chain configs without needing to extend the struts-config syntax. We haven't deprecated the Tiles or Validator plugins, even though we consider them part of the Struts core.
I like the idea of a global "Struts" object, which would be a natural place to configure a list of one or more chains.
Ultimately, I don't have a strong opinion about how this happens, although I thought it would be nice to leave out the Plugin. I guess at least making it optional would be about as good.
I'm ok with all the ideas about inheritance too, although I'd hate to see those bog down acceptable-if-not-perfect forward progress on getting the Chain in front of more people.
> >>>- The controller would have additional optional attributes:> getCatalog(). If no command is specified, then these default values
I think the controller should simply have optional command and catalog attributes which would be used like this:
CatalogFactory.getCatalog(catalog).getCommand(command)
if no catalog is specified, the "default" catalog is retrieved withwould be used: catalog = struts command = servlet-complete
I believe that's what's in place now.
Yeah; I was just trying to articulate, especially because I thought Don was headed in a different direction.
> If catalog were specified without a command, an exception would be thrown.
I am still inclined to package most of what is now struts-chain separately from the core.
I'm not so sure I agree here. Most, if not all, of the commands you list below are used by the chain that you suggest as a default above. I think if we want the ComposableRequestProcessor to be the default for 1.3, we really need to keep the commands in the core as well.
However, I do think they should be pushed into a separate package. Just as we have o.a.s.actions, we could have o.a.s.chain.commands for these.
My main rationale for this is a sense that the commands as they are are unfinished business. As noted, I'd like to see us move towards using a StrutsContext/ActionContext in them, and I think we could merge the abstract classes with the concrete implementations without anyone feeling much pain and simplifying things a lot for new users who come along and want to understand and extend the chain. It seems a shame to import 30 classes if half of them will be going away as soon as we can get around to it. (Anyone who was involved in that original design is encouraged to step up and defend it! Maybe I'm just short-sighted, or plain thick?)
Also, if the default chain-config is (or may be) read from the classpath, then having that in the core struts requires you to override it. Including it instead in a separate JAR means you could remove one and add in another and still get the auto-config feature. Does it help to compare it to taglibs, which we are also talking about removing from the core and including as a separate JAR? You could even draw an analogy between the chain-config.xml and a TLD file.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
