Similar problem here. For legacy reasons we have to wrap an inhouse framework around Struts which is used by a number of application teams. Since we needed to override some RequestProcessor method, we had to choose between TilesRequestProcessor and RequestProcessor. We picked TilesRequestProcessor, even though most of our applications are not using Tiles. Six months ago we entered a bugzilla ticket (#15969) asking for the TilesRequestProcessor to behave more friendly towards applications that do not use Tiles, which has been tagged for later resolution.
Of course, it would be a better to have a generic solution to this problem, such that applications that have no need for the Tiles feature do not have to incur the weight of the TilesRequestProcessor... Dirk Heydtmann -----Original Message----- From: Matthias Bauer [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 2:47 To: Struts Developers List Subject: Re: composable RequestProcessor The Struts Workflow Extension (http://www.livinglogic.de/Struts/) has exactly the problem you are describing. It needs to overwrite the standard RequestProcessor and the TilesRequestProcessor. In order not to duplicate any logic, I needed to come up with a class hierarchy I am not 100% satisified with. Thus, I am very much in favour with a more composable RequestProcessor. However, I totally agree with David, that it is sufficient to provide a RequestProcessor interface, instead of choosing the configuration file approach. But I don't see a reason why this needs to be deferred until Struts 2.0. Why can't the RequestProcessor interface be part of Struts 1.2? --- Matthias Joe Germuska wrote: > Has anyone else wished that RequestProcessor were more composeable? > That is, we have come upon a case where we need to override the > behavior of a single method in RequestProcessor, but we feel a little > sketchy about closing off our ability to use other tools which > override RequestProcessor (like Tiles). Technically, we could just > extend the TilesRequestProcessor, which works even if you aren't using > tiles, but that's a stop-gap. > > I'm sure other people have thought about how to make the > RequestProcessor composeable of smaller handlers for each life-cycle > method... but I thought I'd see what thoughts were out there before > riffing on my own ideas. > > I "staked out" > http://nagoya.apache.org/wiki/apachewiki.cgi?RequestProcessor on the > Wiki as an alternative area for discussion, but of course, if people > prefer to use the mailing list, I'll be watching... > > Joe > > >
