struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
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 

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,

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:

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.

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?)...


So, the following classes are probably broken:

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 Germuska *    

"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:
For additional commands, e-mail:

View raw message