While at ApacheCon, Don, Martin, and I had a chance to chat about refinements to the Struts Roadmap <http://struts.apache.org/roadmap.html>. Here are my notes for everyone's review and comment.
Man, sounds like fun! I wish I could have been there; I've been thinking about ways to get started on 1.3 stuff all weekend, but kind of wishing for higher bandwidth dialogue about specific steps than the mailing list can provide. Ah, well.
Where would ActionCommand fit in, more specifically? Is the idea that you'd rig the chain to use a different command that fills the general role of the current "ExecuteAction" command? Did you guys come up with more specific APIs for the ActionContext and ViewContext?
I like the longer-term ideas on the roadmap, although to be honest it seems a bit conservative to stretch out some of these changes across four minor revisions. I'm sure when we get to talking about how we'll really implement the things, we'll get a clearer picture on whether that is the right timing or not.
I'm most interested in moving forward with making the long-discussed changes on the request processor, but I'm reluctant to just dive in. So, having changed the subject line, I'd like to get a thread going on just how we're going to do this. Here are some of the things I've bumped up against while thinking about it...
* Presumably we don't want to gut the original RequestProcessor class, but rather, change the default implementation class as specified in ControllerConfig? Or maybe we do gut it, but we make a LegacyRequestProcessor which contains the code from the current version?
* How would we get the chain catalogs initialized? If we're really "integrating" this, then presumably we want to scrap the CatalogConfiguratorPlugIn and achieve that in some other way?
The idea of adding yet another property to ControllerConfig kind of irks me. Should we try to find a more graceful way to initialize the controller, perhaps with nested XML elements for the RequestProcessor and the MultipartRequestProcessor? (Here's a case where the Spring BeanFactory starts to look more appealing than Digester, since it's trivial to add new XML to instantiate and relate new beans. Still, extending the Digester RuleSet isn't hard once we agree to the details. )
Perhaps the catalog initialization belongs in the ActionServlet (via init params), so that the servlet can cleanly handle cleaning up the factory at shutdown; then the ControllerConfig could just have the name of the catalog and base command which should be executed for requests for that controller? (the current CatalogConfiguratorPlugIn uses servlet init parameters for this, but it seems to me that these should be per-module settings, no?)
* The current chain project is a lot of classes. Would it be anti-integration to keep it a separate artifact and have people include a struts-legacy-chain.jar as an app dependency? This has some appeal to me also because it is so oriented towards legacy and backwards compatibility. This also brings up something that has been bouncing around in my head for a while -- the idea that a JAR might include a catalog config XML in the JAR itself which would somehow make it more automatically usable. This would let people who really don't care never even look at the chain-config.xml. Or is that too much invisibility?
I guess that's enough questions for now.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
