The other question here is simply whether to change the behavior of the class named RequestProcessor (probably copying the current behavior to a LegacyRequestProcessor) or rather to change the default class used to point to a new class which implements the Chain-based processing.
I like for former. We continue to use RequestProcessor, but deprecate it, and make LegacyRequestProcessor the default. This allows Struts extensions to make the transition easier.
When I said "copy", I meant copy o.a.s.action.RequestProcessor to o.a.s.action.LegacyRequestProcessor, but of course that's a no-go, because any classes which extend it (including ComposableRequestProcessor) would be knocked out of whack. I clearly wasn't thinking.
I think it would probably be adequate to move the ComposableRequestProcessor into struts-core (changing the name or package if appropriate) and making it the default classname returned by ControllerConfig.getProcessorClass:
/**
* The fully qualified class name of the RequestProcessor implementation
* class to be used for this module.
*/
protected String processorClass =
"org.apache.struts.action.RequestProcessor";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]
