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. ;-)
Do you envision Struts 1.2.x releases including chain code? I hadn't thought of it that way, but I suppose there's no fundamental reason not to. But it probably makes sense to keep the plugin for that scenario anyway, since at least in theory Struts 1.2.x should work with Servlet 2.2, and thus couldn't use ChainListener.
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. ;-)
I think I'm just fascinated with the idea of self-contained JARs that you can just drop in. I still like the idea, but if others feel we'll make better progress without it, I won't make a fuss. One person on the user list liked the idea of a separate jar, for what it's worth. I don't remember any specific comments regarding the idea of just merging it into core. I can make time if there's interest in this just waiting for someone to do the work. But if others feel it's not worth it, I am ready to drop it.
> Also, if the default chain-config is (or may be) read from theclasspath, 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?
CatalogFactoryBase overrides:
http://jakarta.apache.org/commons/chain/xref/org/apache/commons/chain/impl/CatalogFactoryBase.html#90
(OT, line-linkable source code is one of my favorite for-free features of Maven)
The Catalog interface is rich enough to support an alternate CatalogFactory implementation which augmented instead, if we wanted that kind of behavior.
You're right that in most cases people would want to augment instead of replace the default chain. Regarding loading a default, my thought was that it would only be loaded if NO other chain configs were specified. As soon as one were specified, the base one would be ignored. It's just as well, because there's really no way (as far as I can see) to augment the chain without making at least some changes to the config file. You'd at least have to be able to get in there to specify an alternate catalog in which to look up a command, unless we figured out some way to parameterize it.
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]
