Patrick, as we discussed on IRC, I've been working on this. I've
basically got the Interceptor framework built, I think, although I
haven't tested it :-)
I'm not sure what you were thinking, but mine does not plug in at the
ActionFactoryProxy level. Basically what mine does is to mimic the way
the javax.servlet.Filter works. Basically, you register all of your
interceptors at the top of your xwork.xml like so:
<interceptors>
<interceptor name="timer"
class="com.opensymphony.xwork.interceptor.TimerInterceptor"/>
<interceptor name="logger"
class="com.opensymphony.xwork.interceptor.LoggingInterceptor"/>
</interceptors>
The DefaultConfiguration builds a Map of the names to instances of these
classes (my thought here being that interceptors should be stateless, so
we only need one instance of each and we can just push invocations
through it), then, in your action declaration, like there are result
references, you have something like this:
<action name="Foo"
class="com.opensymphony.xwork.action.SimpleAction">
<action-params>
<param name="foo">17</param>
</action-params>
<results>
<result name="success" type="chain">
<result-params>
<param name="actionName">Bar</param>
</result-params>
</result>
</results>
<interceptor-ref name="timer"/>
<interceptor-ref name="logger"/>
</action>
DefaultConfiguration then builds an InterceptorChain with the list of
Interceptors and the Action. The interceptor chain has a method,
doInterceptor() which does this:
public String doInterceptor() throws Exception {
if (interceptors.hasNext()) {
Interceptor interceptor = (Interceptor) interceptors.next();
result = interceptor.intercept(this);
} else {
result = action.execute();
}
return result;
}
The sub interceptors can choose to pass the call through by using the
InterceptorChain passed in by doing interceptor.doInterceptor() again.
My base Interceptor implementation does this:
public String intercept(InterceptorChain chain) throws Exception {
before(chain);
String result = chain.doInterceptor();
after(chain);
return result;
}
Which allows subclasses to put code before and after the rest of the
processing.
What happens in GenericDispatcher is this (replacing the direct
execute() of the action):
List interceptors = actionConfig.getInterceptors();
InterceptorChain interceptorChain = new InterceptorChain(action,
interceptors);
result = interceptorChain.doInterceptor();
Anyway, that's what I've been working on... Thoughts?
Jason
> -----Original Message-----
> From: Patrick Lightbody [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 09, 2003 10:24 AM
> To: os-ww
> Subject: [OS-webwork] XWork Interceptors
>
>
> So anyway, I'm just going to disregard the "Documentation"
> thread and start a thread that is actually useful :)
>
> (Though, Ken, we're still hoping your willing to do some Doc work!)
>
> So besides Action Chaining, Rickard made a good point that
> interceptors is very important as well. I'd like to talk
> about the actual implementation now -- using the transaction
> scenario as an example.
>
> How will the interceptor know when to rollback or commit? Of
> course on an Exception it should, but what about on ERROR or
> INPUT? What if the action, to signify it's is complete, used
> COMPLETE instead of SUCCESS? Do you see my point? How can we
> make interceptors work for all cases? I'm guessing some sort
> of configuration is needed for each interceptor on each
> action, so we could do something like:
>
> <interceptor class="...">
> <param name="commit.values">success, complete</param>
> </interceptor>
>
> And then the interceptot could know to rollback if the return
> value isn't one of those two.
>
> Rickard, is this what you had in mind?
>
> Also, Interceptors would fit in to the GenericDispatcher
> area. I think that they would replace ActionFactoryProxies
> entirely, correct? Also, maybe Rickard you can provide some
> sample psuedo code for an Interceptor as well as how it would
> go about being invoked in GenericDispatcher?
>
> -Pat
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something
> 2 See! http://www.vasoftware.com
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
