I continue to have misgivings about positioning the new controller with multi-configuration support as an incremental update to the existing package. I'm totally on-board with the new controller, but want to be sure that we are fulfilling our responsibilities to the many professional teams using Struts in production, and not creating any unnecessary confusion or undue hardships.
The degree of backward compatibility provided is impressive, even stunning. This will ease the migration for countless applications, and save people untold development hours. But, do we need to abandon the existing controller package in the process? What failsafe is there for production installations should a problem be uncovered? What impact will there be on existing applications that do not need to use the new capabilities? How will extensions, akin to Tiles, handle the low-level incompatibilities? Will this approach increase or decrease our own support and development costs? Will it hinder our ability to release a 1.1 version in a reasonable time frame? What procedural options do we foreclose? Here are some points that have occurred to me: 1. The new package, while extremely compatible, is admittedly not fully compatible. 2. The new package enhances functionality only if changes are made to the deployment descriptor, and certain navigation patterns are followed throughout the application. 3. That the new package is extremely compatible does not benefit people using the existing package. 4. That the new package is not fully compatible may potentially harm people who do not wish to use the new functionality at this time. 5. If once released, problems are discovered in the production deployments, there is not a clear regression path or failsafe. Other changes made for the 1.1 release would have to be undone in order to use the original ActionServlet. 6. The only clear technical benefit to retaining the package name is that import statements would not need to be updated. But since other import statements would need to be changed to deploy 1.1 (see point 5), this benefit is negligible. 7. If the new package is released under a new name, the potential for harm is negated. The practical benefits are still available to those who wish to use the new package, and make the minor adjustments required to make use of the enhanced functionality. 8. The existing package is not broken. The likelihood that it will require maintenance is negligible. If we declare that the original ActionServlet is feature-locked, we are not obligated to change it in any way. All new functionality can be bundled with the new controller. 9. Other components, and some servlet subclasses, that rely on the existing package's low-level functionality may not compile against the new package. Others may compile, but may not execute properly. 10. Such components will need to provide duplicate distributions. One that links with the 1.0 ActionServlet, and duplicate distribution that links with the 1.1 ActionServlet. 11. If the new package was given a new name, these packages could continue to link against the existing ActionServlet, and develop a companion package for the new ActionServlet, which could co-exist in the same distribution. 12. By not renaming the package, our own maintenance costs are not diminished (since they are effectively zero), but the maintenance cost of other components will be significantly increased. 13. Giving the new package a new name will reduce the maintenance cost of dependent components by allowing a single distribution that works with either controller. 14. By not renaming the package, our own support costs will certainly increase, as the inevitable questions regarding the subtle differences between ActionServlet 1.0 and ActionServlet 1.1 cross the lists. 15. Giving the new package a new name will reduce our own support costs, by clarifying that the two controllers are not fully compatible. 16. New functionality in the new package deprecates a great many features of the existing package and this will also create significant support traffic on the lists, even when the developers are not ready to use the new functionality. 17. Giving the package its own name does not dilute the importance of backward compatibility, since most people will be bringing forward existing applications. In this case, the deprecations are important and appropropriate, since the developer has made an affirmative decision to suffer or address the deprecations in order to make use of the new functionality. People moving forward will be grateful for the compatibility, and people not moving forward at this time will be unaffected. 18. If we restore the original ActionServlet package, we could be able to move to an immediate 1.1 release candidate that does not yet document the new package. 19. An early 1.1 release candidate will expose the many other new features for final testing. In the meantime, work could continue on documenting, testing, and possibly refining the multiple configuration and Dynabean support. We could consider introducing declarative exceptions and the execute signature with the new controller, to emphasize that the existing controller is locked. 20. Documentation for these features could be merged into the (undoubtedly unavoidable) 2nd release candidate, 0r even into a 1.2 release, if, at a later date, that is deemed prudent. 21. Renaming the new package will allow us to abbreviate the 1.1 release candidate cycle, and put a final release into the marketplace more quickly. So, to try and talk us down from the ledge, I propose that we A. Select a new name for the multi-configuration controller. B. Restore the preexisting 1.1 Action package to a state fully compatible with 1.0. C. Introduce the execute method and declarative exception handling with the new controller. D. Complete what is needed to cut a 1.1 release candidate documenting the other new functionality. E. Introduce the new package in the second release candidate. F. Deprecate the 1.0 controller in a 1.2 timeframe, and then make the new package the standard controller. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
