struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Evans (JIRA)" <>
Subject [jira] Reopened: (STR-1102) Ability to use TilesRequestProcessor even if it not initialized from TilesPlugin
Date Tue, 02 May 2006 00:42:19 GMT
     [ ]
David Evans reopened STR-1102:

    Assign To: Don Brown  (was: Struts Developer Mailing List)

> Ability to use TilesRequestProcessor even if it not initialized from TilesPlugin
> --------------------------------------------------------------------------------
>          Key: STR-1102
>          URL:
>      Project: Struts Action 1
>         Type: Improvement

>   Components: Tiles
>     Versions: Nightly Build
>  Environment: Operating System: other
> Platform: Other
>     Reporter: Dirk Heydtmann
>     Assignee: Don Brown
>     Priority: Minor
>      Fix For: 1.2 Family

> Cedric suggested I put this as an enhancement request in bugzilla, with the 
> goal of being able to use the TilesRequestProcessor even if it not initialized 
> from the TilesPlugin.
> We would like to propose making the TilesRequestProcessor tolerant to where it 
> does not choke on a regular (non-Tiles) application. Actually, the 
> TilesRequestProcessor already "sort of" supports this, but not entirely.
> Background:
> In our company we have a legacy MVC framework that now wraps around Struts 1.1, 
> and this legacy framework has its own request processor that needs to extend 
> either the TilesRequestProcessor or the standard Struts RequestProcessor. Since 
> we would like to keep things simple and do not want to duplicate our code, we 
> want to extend just one request processor class, not both. That is why we 
> decided to extend the TilesRequestProcessor and have our request processor be 
> used for both Tiles and non-Tiles apps. Below are the issues we ran into using 
> this approach with Struts 1.1 beta 3, and how we worked around them.
> == Issue 1 ==
> TilesRequestProcessor expects the TilesUtil implementation of type 
> TilesUtilStrutsImpl. But unless there is  TilesPlugin configured, nobody sets 
> this implementation. As a workaround, we extended the ActionServlet and in its 
> init() we are explicitly setting the implementation with "TilesUtil.setTilesUtil
> (new TilesUtilStrutsImpl());"
> == Issue 2 ==
> TilesRequestProcessor's initDefinitionsMapping() logs an error, if a 
> DefinitionsFactory has not been set, i.e. if the TilesPlugin hasnot been 
> configured.
> Proposed fix: downgrade message to "info".
> == Issue 3 ==
> TilesRequestProcessor.processForwardConfig() could be optimized to where first 
> thing it does it checks a flag that indicates whether we are really running 
> with a TilesPlugin, and if not, it would immediately delegate the call 
> to "super". Again, this would be just optimization, allowing the call to skip 
> over all the logic in processForwardConfig() and processTilesDefinition().

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message