mrdon 2003/10/23 19:35:02Welcome to the "Chain Gang" Don! :-)
Modified: contrib/struts-chain/src/conf chain-config.xml
Added: contrib/struts-chain/src/java/org/apache/struts/chain
AbstractAuthorizeAction.java
AbstractRequestNoCache.java
AbstractSelectForward.java
AbstractSetContentType.java
contrib/struts-chain/src/java/org/apache/struts/chain/servlet
AuthorizeAction.java RequestNoCache.java
SelectForward.java SetContentType.java
Log:
Adding in some missing pieces. Pretty much straight one-to-one mappings of
RequestProcessor methods to chain actions.
I noticed that your implementation of AuthorizeAction does the same thing that the current Struts RequestProcessor does if authorization fails -- sends a "Bad Request" (status 400) message back. One thing we might consider instead is throwing a Struts-defined authentication exception, which would allow the exception handling mechanism to decide what to do instead.
One nice feature of using the chain approach is that the exception handler (o.a.s.c.ExceptionCatcher) can handle exceptions thrown by *anything* that executes after it is installed in the chain, not just exceptions thrown by Actions. This allows us to use exceptions to enable application-defined handling of lots of exceptional events from the framework as well, rather than simply throwing a 400 response. In addition, sending a 400 isn't going to be possible in a portlet world anyway, so we might as well start thinking about what to do instead, and make it consistent in servlets as well.
What do you think?
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
