Yes, I would like to start by introducing the new interfaces as "experimental" and not start deprecating members until we are sure of the migration path. Later, when the time comes, if there was solid support in the community for removing the legacy classes, then yes, the rest could follow. Though, I suspect that once we get there, we may find that it is just as easy to leave the original members in place, or available through a supplemental "struts-classic" JAR, so that the new can be used alongside the old.
When a project becomes as popular as Struts, keeping all of our friends, silver and gold, is vital to the health of the community. A lot of people (including ourselves) have a lot invested in "Struts Classic", and we want to be sure that there is a clear migration path. For example, if we ever want to make significant changes to the XML configuration, we could use XSLT to transform an existing configuration into a new format at load-time. Using transformations might be a cool way to switch to Spring under the covers, but still provide support for a IDE-friendly DTDs. The cool thing about the composable request processor is that the "gear-heads" can edit the Chain to use only the components they need. Chain also eliminates the complexity of "special-case" branching. By giving everyone a "bite at the apple", special cases (like XSLT pre-processing) can be cleanly handled by separate commands. -Ted. On Mon, 06 Dec 2004 16:59:44 -0600, Hubert Rabago wrote: > On Mon, 6 Dec 2004 07:02:12 -0500, Ted Husted <[EMAIL PROTECTED]> > wrote: > >> I'd suggest that we plan on adding new interfaces in 1.3.x, so >> that people (incluiding us) can start migrating to contexts, but >> that we hold back on new deprecations until we've had some time >> to work with contexts and new signatures. Once we have it sorted >> out, and have working examples in the distribution, then we can >> start deprecating (what will then be) overlapping signatures. >> >> So, we might start by adding experimental context-based >> interfaces and signatures in 1.3, deprecate overlapping >> signatures in 1.4, and then start removing obsolete members in >> 1.5. >> > > If so, then to further clarify: > In 1.3, Actions and ActionForms written for 1.2 would work, and > will not even get deprecation warnings at compile time. In 1.4, > Actions and ActionForms written for 1.2 would still work, though > some methods would be deprecated. > In 1.5, Actions and ActionForms written for 1.2 would no longer > work. > > Right? > > Hubert > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
