DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15969>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15969 Ability to use TilesRequestProcessor even if it not initialized from TilesPlugin Summary: Ability to use TilesRequestProcessor even if it not initialized from TilesPlugin Product: Struts Version: 1.1 Beta 3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Tiles framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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(). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
