At 8:36 AM -0800 1/16/04, David Graham wrote:> I'd propose moving that from the RequestProcessor into theModuleConfigImpl. This would then also involve removing a similar fallback that I committed to the struts-chain AbstractSelectAction class yesterday.
How would removing it from RequestProcessor affect backwards compatibility? Could subclasses be relying on the fallback being there?
The fallback is inside processMapping(). processMapping already calls moduleConfig.findActionConfig() so the behavior would be identical.
Whoops. I take that back. If anyone is using a different implementation of ModuleConfig, they may be relying on that behavior. I forgot since ModuleConfig is one of the few interfaces at that layer of struts.
ModuleConfig doesn't mention any fallback strategy in the doc for findActionConfig():
"Return the action configuration for the specified path, if any; otherwise return null."
It's arguable that the wildcard mapping in ModuleConfigImpl honors this, but that returning the unknown action would not. Strictly speaking, perhaps this change isn't appropriate, and the code to walk through the configs looking for an "unknown" is easy enough to write... I just don't like duplicating it.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining."
-- Jef Raskin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
