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

Here are some points that have occurred to me:

1. The new package, while extremely compatible, is admittedly not fully

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

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

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]>

Reply via email to