Good point about the original RP still being present and usable... but, I would assume (although I can't say with any authority) that there are significant changes (not functional) besides the RP piece, would that be accurate? If so, my point I still feel is valid, although perhaps diminished a bit :)
That's a good question. It deserves more clear documentation, but the per-action and per-forward command processing will not work with the base RequestProcessor. While it is logically plausible to add lookup processes in the base RequestProcessor, there remains the question of how the ActionContext would be instantiated. It would be easy enough to push the contextInstance() method up to the base RequestProcessor, but it might leave unclear some semantics: would the base RequestProcessor pay attention to any values added to the context by chain commands? Commands could make changes to the request and the session, but if, for example, they set the context's forwardConfig property, I'm not sure it's clear whether (or how) the base request processor should pay attention to that.
Besides those, I can't think of any new-in-Struts-1.3 functionality which wouldn't work as well if you told Struts to use the original RequestProcessor instead of the ComposableRequestProcessor -- if we went ahead with changes to the Action interface, this might be harder to promise, so that's probably a good baseline rule for not making that change yet.
(To be honest, I can't think of any other new-in-Struts-1.3 functionality, except for the arbitrary properties on ForwardConfig. Most of the other work has been on the repository.)
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]
