Could you configure the Tiles plug-in first and then have your own plug-in swap in your RequestProcessor implementation that extends TileRequestProcessor? Then you might not need to extend ActionServlet. Not sure if you can be sure what order the plug-ins run. Just a thought, haven't looked into it.
> -----Original Message----- > From: Heydtmann, Dirk [PCS] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 08, 2003 6:31 PM > To: Struts Developers List > Subject: TilesRequestProcessor in non-Tiles applications > > > Hello: > > 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 two 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 a > TilesPlugin configured, > nobody sets this implementation. > 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 has > not been configured. > Workaround: non needed, this is just a nuisance. The > TilesRequestProcessor still works OK. > > Thoughts? > > > Dirk Heydtmann > Sprint PCS - CAM Architecture > (913) 794-4671 > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
