Martin Cooper wrote: > 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.
I haven't been able to trace everything back, but I have run into issues with the new controller looking for an ActionConfig object if I get my pre-BIG and post-BIG 1.1 JARs get confused. This may be a Tiles-related issue (which would also apply to any ad-hoc Tiles-like enhancements people have made). My core issue is that we really had enough for 1.1 release before the new servlet. Now if for any reason they cannot use the new servlet, then we have effectively locked them out of the reset of the 1.1 codebase, with falling back all the way back to 1.0 being the only ready alternative. > 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. Again, this is my point. I'm concerned that we are linking a rather big, extremely cool change with all these very useful, but somewhat boring incremental changes, and not providing developers with enough granularity. > 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. Here I refer to the the switch from 1.0 to 1.1, where we changed over to the Commons packages. > > 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. I don't believe the "broken" issues relate to the ActionServlet package. If they did, then they should also be part of a 1.0.3 release. > > 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. The point is that if distributing both servlets did not create a lot of duplicate code, why can't we have both? People who can't use the new one for some reason, say they extended the ActionServlet in unseemly ways, can continue to use the original servlet, and still be able to use the other new features. Some of these features have been in place since right after 1.0 was released. If distributing both servlets does create a lot of duplicate code, then I would anticipate that once this gets out of the laboratory, we will find a lot of people with compatibility issues. > 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. ;-) That's certainly good news! Unfortunately, my substantial applications are based on Tiles, and so I haven't been able to test the new servlet with my real production applications, nor have I been able to start retrofitting these for multiapps. I'm eager to do this, but having to do it just makes a 1.1 release-candidate seem farther away then ever. > 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. Which underscores my other main point. If not for the new servlet, we could go to a 1.1 release-candidate with the other new functionality, and have a final release in circulation for JavaOne. We had in fact talked about doing that, and the 1.0.x releases were to be preludes to a 1.1 RC. The new servlet is going to require more testing and more changes to the documentation, which is keeping the rest of 1.1 out of the hands of teams who are not permitted to use Nightly Builds in production. Unfortunately, many organizations I work with treat this as a Prime Directive. The magic "release" stamp means a lot. Based on the pre-BIG codebase, we can definately have 1.1 out for JavaOne. It would still be ~possible~ with the new servlet, but, realistically, by no means assured. I'd also like to get away from these monolithic releases, and try to develop a more step-wise pattern, so as get things out to the production teams more often than once a year. > 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. I believe that the multiapp support is the greatest thing for Struts since, well, since Struts. This will really open Struts up for use by larger teams and even larger applications. We will quickly seen snap-in Strutlets, and power users building entire applications just by assembling things other people have built. We will not have any problems in finding lots and lots of people to test this. The Bad Thing, I think, is forcing people to buy into the new servlet just to make use of all the other changes made this year. Again, I do think the new servlet is a Good Thing, an engineering marvel, really. But we have positioned Struts as a framework for serious, professional teams, and it is incumbent upon us to be conservative. Or, to at least thoroughly consider the most conservative path before rushing forward, burning bridges as we go. -- Ted Husted, Husted dot Com -- For priority Struts support, -> visit http://husted.com/about/services -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
