struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <...@Germuska.com>
Subject Various Module bugs in Struts 1.3.x (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
Date Tue, 16 May 2006 19:17:16 GMT
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
Joe@Germuska.com * 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message