----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Sunday, February 17, 2002 6:07 AM Subject: [PROPOSAL] Modular Applications (the BIG checkin) [LONG]
> 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. The only incompatibilities *for the default sub-app* I am aware of are: 1) As Craig mentioned, all requests must go through the controller. 2) The 'mapping' init param isn't supported, but I will fix that. The other incompatibilities that Craig mentioned apply only to non-default sub-apps, so there is no effect on existing Struts 1.0.x applications. Are there other incompatibilities that have been uncovered? > 2. The new package enhances functionality only if changes are made to > the deployment descriptor, and certain navigation patterns are followed > throughout the application. This sounds like "there's no free bonus for using the new package". Well, you can use declarative exception handling without using sub-apps, and you can have multiple resource bundles loaded for you automatically. > 3. That the new package is extremely compatible does not benefit people > using the existing package. I claim that it does. It means that they can add a new sub-app to their existing application without having to change their code to reference a different package. Also, as mentioned above, they can take advantage of declarative exception handling and multiple resource bundle loading. > 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. If there are incompatibilities that cannot be remedied, yes. But that is true of any change we might make from one version to the next. If people don't want to use new functionality, they don't have to upgrade. > 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. I assume you are referring to potential problems which could not be rectified with the new architecture. Anything else could be fixed, if necessary. If people are as eager as they appear to be to use the other new functionality being introduced in Struts 1.1 (indexed and nested tag extensions, declaratoive exception handling, etc), then I would think that the beta and RC cycles should flush out anything else. > 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. I'm not sure what you're referring to here. What import statements need to be changed to deploy Struts 1.1 today? I have not had to change any except where I'm actually extending the new functionality. > 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. It's not a question of one new package. Almost every package was changed in The BIG Check-In, plus one new package added. We'd have to duplicate much of the code base, as far as I can tell. > 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. There are currently almost 100 open issues in Bugzilla, so to some extent it is broken. Of course, we'll be fixing some number of those prior to releasing Struts 1.1 anyway. However, if we have separate packages for the multi-app stuff, then maintenance becomes harder, because each bug potentially needs to be fixed in two places. > 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. This appears to be a suggestion that we may find further incompatibilities along the same lines as those that made Struts 1.0.2 necessary. Those problems arose from ordinary changes, not The BIG Check-In. I think any such problems arising from the multi-app changes would be ironed out during the beta or RC cycles. And it's not hard for people to take the latest code for a spin - it's a drop-in replacement. > 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. We can work to avoid that, should the need arise. > 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. As mentioned above, there's a lot more to it that one new package. > 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. By duplicating so much code, I believe our (i.e. Struts) maintenance costs would be substantially increased. You seem to be assuming that compatibility changes are not possible here. > 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. I guess I don't understand this point. > 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. If there *are* differences that people come across, there may be some additional message traffic initially. In the end, though, our support costs will be substantially reduced by supporting only one package. Certainly, there are many people using Struts today. However, we obviously hope there will be many more. I'd rather not confuse those new people by providing two different packages. And the people who are already using Struts today will have the opportunity to help us iron out any wrinkles there might be during the beta and RC cycles. This seems like a win-win to me. > 15. Giving the new package a new name will reduce our own support costs, > by clarifying that the two controllers are not fully compatible. I think this will *increase* our support costs, since we will continually have to explain why we support two different controllers, and we'll also have to fix bugs in two places. Again, though, I honestly don't believe there will be any notable incompatibilities in the first place. > 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. I'm certainly not aware of "a great many" deprecations. I've seen some, certainly, but as long as we clearly document what we've done in Struts 1.1, I don't see a problem with that. I mean, we deprecated a whole pile of things when we moved pieces of Struts to Commons, and I don't recall seeing all that much mail about those deprecations. I think the number of deprecations with The BIG Check-In is smaller than that. > 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. With duplication of so many classes in so many packages, I think using new packages will make things much worse, if it's even tenable. > 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. Speaking for myself, I'd much rather put my own efforts into making sure that the new multi-app code is complete, and ironing out any incompatibilities that happen to arise. I can probably help in documenting it, if necessary. > 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. In my day job, my team is already starting to build a substantial multi-app application on top of the new code, so we'll be helping flush out any remaining problems (even while we are also extending the new framework). That will help. ;-) As mentioned above, declarative exception handling, and the execute signature, were checked in as part of The BIG Check-In. > 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. I think we're going to want at least one beta cycle before we go to an RC. I say that not just because of the multi-app support, but because of all the other new functionality that has been introduced since 1.0.x. We can most likely get docs done, if not before beta, then before RC1. > 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. Well, as I'm sure you've figured out if you've read this far :-) , I'm in favour of completing Struts 1.1 with the new multi-app support, rather than pushing it off to a later release. As I mentioned earlier, with so many developers eager to use the other new functionality introduced since 1.0.x, we'll get more compatibility testing than we would otherwise get. In particular, if we had a later release for only the multi-app support, then people who didn't want to use that would not bother to test against it, and we wouldn't have nearly as much compatibility testing. That would be a bad thing. -- Martin Cooper > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
