Re: [Springframework-developer] Re: struts integration - alternate approach

[Seth L. <se...@eh...>]

jürgen höller [werk3AT] wrote:
> Dan,
>  
> I've just done some prototypical tests. As far as I can tell, the only benefit of the RequestProcessor approach is that you can write
>  
>   <action path="/test"/>
> 
> rather than
>  
>   <action path="/test" class="org.springframework.web.struts.DelegatingActionProxy"/>
>  
> The disadvantage is that you need to have a special subclass of every RequestProcessor that you might use: at least of the default RequestProcessor and of TilesRequestProcessor. Some amount of code duplication is inevitable there. And if you already have a custom RequestProcessor, you need to subclass it on your own.
>  
> So all things considered, I still tend to recommend the DelegatingActionProxy approach, which doesn't affect RequestProcessor choice at all. Just saving the "class" attribute above does not seem to be enough benefit to accept the RequestProcessor subclass hassle. Is there anything I miss here?
>  
> Juergen
>  
> P.S.:
> I'm forwarding this to developer list for further feedback.

Juergen,

For our integration here, we ended up subclassing RequestProcessor.  The 
reason was because we're using xdoclet to build our struts-config.xml 
file.  So IIRC we couldn't use DelegatingActionProxy (or the similar 
alternatives) because we needed Xdoclet to read into our action classes.

Hope that helps,
Seth