I want to make some changes to the way ActionMapping instances are created, but I'm a bit puzzled about the various related deprecations. Historical help would be appreciated! (Craig?)
Here's what I can tell from the CVS history: 1) The 'className' attribute for the <action> element has been available in the struts-config.xml file since prior to Struts 1.0. It allows customisation of action mapping implementation classes at the per-action-mapping level. 2) At some point prior to Struts 1.0, the 'type' attribute was introduced on the <action-mappings> element in the struts-config.xml file. This allowed the specification of the class to be instantiated for all action mappings as they were parsed from the config file, thus allowing customisation of action mappings at the config file level. 3) Still prior to Struts 1.0, this 'type' attribute was deprecated. The preferred means of specifying a custom action mapping class was changed to the use of a servlet init-param. Although not relevant at that time, in today's multi-module context, this means that the customisation is now at the application level rather than at the config file level. 4) As a part of "The BIG Check-In", the use of an init-param to specify a custom action mapping was deprecated. (In fact, I don't believe this is actually supported in the current code base.) As far as I can tell, the only remaining non-deprecated method of customising the class used for action mappings is to specify the class on a per-mapping basis - that is, (1) above. I don't think this is what we want. (Well, it's not what *I* want :) It seems to me that we should go back to stage (2) above, and allow the specification of the implementation class at the per-config-file level. This would fit well with the new multi-module architecture. Bugzilla #6583 also seems to argue for this. Before I start making changes in this direction, I'd really like to hear about how we got to where we are. The last thing I want to do is repeat the same old mistakes! Thanks. -- Martin Cooper -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
