[jira] Closed: (STR-1102) Ability to use TilesRequestProcessor even if it not initialized from TilesPlugin

["David Evans (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/struts/browse/STR-1102?page=all ]
     
David Evans closed STR-1102:
----------------------------

    Resolution: Fixed

> Ability to use TilesRequestProcessor even if it not initialized from TilesPlugin
> --------------------------------------------------------------------------------
>
>          Key: STR-1102
>          URL: http://issues.apache.org/struts/browse/STR-1102
>      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:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira