Craig, Thanks for the detailed reply. See below.
[snip[ > > > > 1. I don't know if this is carved in stone yet, but IMHO this > is much more > > than a 1.1 release. Perhaps not a 2.0 release, but at least a > 1.5 release. > > The implications of a single point release to me are minor functional > > enhancements and bug fixes. These are substantive, major functional > > enhancements which still provide backward compatibility. Again, just my > > opinion... > > > > I don't consider any of it cast in stone. There are way to many smart > people contributing to the future of Struts for me to have the only good > ideas. > > The reason I still want to call the next release 1.1 is this: despite the > huge number of internal changes, the fundamental APIs for applications > *are* pretty much backwards compatible. That's a promise that was made > early on in Struts development, and I want to honor that. Calling it 1.5 > or 2.0 would raise concerns in people's minds about compatibility -- even > if those fears turned out to be unfounded. I guess my point was that anything "1.x" implies backward compatibility, but a bigger point change implies somewhat substantive functional changes. To Ted - going straight from 1.0.1 to 1.5 wouldn't make me wonder about intervening versions any more than going from 1.2 (or whatever the highest 1.x version of Struts ends up being) to 2.0 will. :) [snip] > > > 4. Breaking out the request processing into RequestProcessor is > also huge. > > ActionServlet plus the config stuff seem like they can now > stand alone with > > pluggable request processing easily able to reuse those elements. > > Yep. A subsequent check-in enabled having different RequestProcessor > instances (and even implementation classes) per sub-application. I noticed that, and I'm hoping to get a chance to revisit the way I'd like to see a RequestProcess be designed. I didn't get that far since I was going about refactoring ActionServlet. But now you've done the dirty work, and it's checked in!!! > > > > > 5. In the new ActionServlet, doGet and doPost are identical. Would it be > > better to delegate their implementations, simple though they are, to a > > protected overridable method? > > > > When it was a single hard-coded request processor instance, the > implementation was one line each - I guess three lines is enough to make a > subordinate method again. I think that's a good idea. Someone may want to override both, and it would be easier to get the "super()" call right if they just have to override the subordinate method. > > > 6. It's a little confusing seeing member variables of type and name > > "FastHashmap actions" in both ApplicationConfig and RequestProcessor. > > Perhaps the variable names could be clarified. > > > > In ApplicationConfig, maybe the variable name should be actionConfigs? > That corresponds to what the Map actually contains. I think that's a good idea. > > > 7. Is the special handling for the default app's ControllerConfig and > > MessageResourcesConfig so that existing web.xml files will > still work for > > setting those parameters? > > > > Yes. It actually took just as long to figure out how to deal with this as > the rest of the design. Do you think it's possible to target the eventual deprecation of that capability - i.e. requiring thos parms to be in struts-config.xml, even for the default app? I understand the reasoning now, but I think it will be confusing to newcomers in the future and could cause support issues if someone drops in a struts-config.xml file with those values set and intends it to configure the default app. One other question I forgot to ask - you've marked findDataSource and destroyDataSources as deprecated. Should that not also make the dataSources FastHashmap member variable deprecated. It would seem that since the datasources are stuck straight into the context, Struts can let the container manage them and eliminate having to manage them itself. > > > 8. ActionForward and ActionMappings both still retain references to > > ActionServlet, and in both cases it seems primarily to allow > the user of an > > ActionForward or ActionMappings to get a reference to the > servlet. With the > > drastic changes to ActionServlet, what method on ActionServlet would the > > user of an ActionForward or ActionMappings need to call? I > guess what I'm > > saying is that it would be nice to deprecate and/or remove those > > getServlet/setServlet methods from those classes if they're not really > > required, esp. if the "best practice" way to get to a resource > is through > > one of the contexts. FWIW... > > > > Deprecation is probably a reasonable idea, but I want to walk through the > code paths to see if the servlet references are used internally anywhere > first. I did searches throughout the base code and didn't come up w/ anything. My biggest concern, and why deprecation would be preferred, is if there are derived ActionForward / ActionMapping classes that think they need access to it. But they're likely broken anyway since, I believe, a lot of the API they'd expect from ActionServlet is gone/moved. One more question, on a philosophical note. I notice that you make your member variables protected. Is this an explicit design decision? If so, may I ask why? Not trying to stir up a hornet's nest, but as an old C++ hand, I'm reared in Stroustrup's disdain for such a practice. ;) Thanks again. Donnie [snip] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
