At 1:07 PM -0500 5/16/06, Joe Germuska wrote:
I've uncovered a couple of things in porting an old Struts 1.1
application to 1.3; I know they probably need to go in Jira, but I
wanted to get a little discussion about them before filing them.
Actually, now I think i'll send them separately with different
subject lines to help manage the various conversations that might
arise...
This bug has taken a pretty long time to surface, I think mostly
because modules are relatively infrequently used, but I think it
constitutes a bug which should be fixed. I'll describe and get some
feedback before posting to JIRA or changing.
In Struts 1.1, the TilesRequestProcessor derived the "base" URI
(usually a JSP) from a given tiles definition and asked Struts to
forward or include. See
http://svn.apache.org/viewcvs.cgi/struts/action/tags/STRUTS_1_1/src/share/org/apache/struts/tiles/TilesRequestProcessor.java?view=markup,
particularly "processTilesDefinition" and "doForward"
In Struts 1.3, the TilesPreProcessor tries to do the same thing by
changing the ActionForward in the context before deferring to other
commands in the chain:
http://struts.apache.org/struts-action/struts-tiles/xref/org/apache/struts/tiles/commands/TilesPreProcessor.html#218
Thus, the TilesRequestProcessor causes a forward to happen directly
to the derived path, while PerformForward prepends the
ActionContext's moduleConfig's prefix to the tiles base path.
In tracking the code a little further, I think that PerformForward
may also be handling modules incorrectly. It always uses the
context's moduleConfig if the ForwardConfig's path begins with "/",
so even if a ForwardConfig has its module property set, that property
will be ignored.
http://struts.apache.org/struts-action/struts-core/xref/org/apache/struts/chain/commands/servlet/PerformForward.html#69
PerformForward should be consulting the module property of the
ForwardConfig and using it to select (if appropriate) a module, more
like SwitchAction (which actually probably doesn't work either, since
its call [1] to ModuleUtils.getInstance().selectModule(...)[2]
doesn't actually change the ActionContext!)
(and now I'm beginning to realize why I've advised my team not to use
modules in new development! I certainly don't understand the
details; does anyone consider themselves expert in using modules?)...
[1]
http://struts.apache.org/struts-action/struts-extras/xref/org/apache/struts/actions/SwitchAction.html#95
[2]
http://struts.apache.org/struts-action/struts-core/xref/org/apache/struts/util/ModuleUtils.html#235
So, the following classes are probably broken:
TilesPreProcessor
PerformForward
SwitchAction
I'm not sure I see the best way to straighten these things out -- I
could hack things up, but maybe someone who is more fond of modules
could consult?
Joe
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
