Looks great Jason! Can't wait to see it!
-Pat
----- Original Message -----
From: "Jason Carreira" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 09, 2003 7:43 AM
Subject: RE: [OS-webwork] XWork Interceptors
> 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
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
