On Fri, 17 Dec 2004 13:32:16 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > >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.
We could do the following: 1) Toss the plugin and rely on ChainListener to load everything. I know this goes back to adding entries in web.xml, at least for 1.2.x. But then ... 2) We can add config for chains in struts-config.xml in the 1.3 code. This doesn't have to be tied to the process of adding <extends> support - we could do that at some later time. I suppose (2) doesn't really make the plugin go away. It just causes the code to be morphed a bit and embedded into the Struts config reading process. ;-) > 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. Agreed. > > > >>>- The controller would have additional optional attributes: > >> > >> 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 with > > > getCatalog(). If no command is specified, then these default values > >> would 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?) Yes, it would be nice to understand the rationale for the way things are now. ;-) I think, though, that it's going to be easier to get to where we want to be if we don't have to mess around with two separate subprojects. With moving and deleting things in SVN being as easy as it is, I think it would be fine to bring in what's there now. If we do think many of those will go away, then perhaps they should live in a 'legacy' package until we know what we really want. Then again, if Don is going to do the work of bringing struts-chain into the mainstream, perhaps we should let him make the call. ;-) > 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. I would expect that the most common reason for overriding the default chain config would be adding some extra commands into the chain, in which case you'd want all of the original struts-chain except for the chain config file (or at least you'd want a way to override the default). So I'm not sure this is a reason to keep them separate. How the default chain is overridden is a good question, though. If we set things up so that the default is loaded automagically, then overriding it would have to be done with explicit config somewhere - plugin or web.xml. But I'm not sure what happens when two config files with the same catalog name are loaded. Would a second "struts" catalog overwrite the first, or augment it? -- Martin Cooper > 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]
