Re: [OS-webwork] XWork Interceptors

[Rickard Öberg]

Patrick Lightbody wrote:

So anyway, I'm just going to disregard the "Documentation" thread and start
a thread that is actually useful :)

Good idea :-)

(Though, Ken, we're still hoping your willing to do some Doc work!)

Same here!

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?

In this particular case I think it's best to look at how EJB works: for any application result from a method invocation (e.g. void, some value, an application exception) the transaction is committed. The transaction is ONLY rollbacked if a) a runtime exception was thrown b) setRollbackOnly() has been called. I.e. the interceptor does not need to be configured.

So, what if you (for some reason) really do want ERROR to lead to a rollback? Well, simply add an interceptor that on ERROR calls setRollbackOnly, and have it after the tx interceptor (i.e. it is invoked before the tx interceptor on the "way back"). Have *that* interceptor be configurable, and add it whereever you want this kind of behaviour. That way the tx interceptor itself is nice and clean, and you can still get app-specific behaviour at some points.

Also, Interceptors would fit in to the GenericDispatcher area. I think that
they would replace ActionFactoryProxies entirely, correct?

Yup. In my XWork implementation ActionFactory is now just a class that instantiates an action directly, and initializes the interceptor chain for it. Everything that the AF proxies used to do is now in interceptors that are executed on execute() invoke. This means that the GenericDispatcher is typically not needed. Just do this:
Action action = ActionFactory.getAction("foo");
action.execute();

And this can be done *within* another action without problem.

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?

As I said, I don't think GD is needed anymore. Here's an example interceptor I wrote:
public class ParameterInterceptor
implements ActionInterceptor
{
// ActionInterceptor implementation ------------------------------
public String execute(ActionInvocation invocation)
throws Exception
{
// Set parameters
TypeConverter typeConverter = Configuration.getInstance().getAction(invocation.getName()).getTypeConverter();

OgnlUtil.setProperties(ActionContext.getContext().getParameters(), invocation.getAction(), typeConverter);

return invocation.next();
}
}
--
This replaces the action factory that transfers servlet parameters to the action. Pretty straightforward. Note that the ActionInvocation is a temporary object, i.e. it contains request-specific information in addition to the static interceptor chain.

/Rickard

--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic

Got blog? I do. http://dreambean.com



-------------------------------------------------------
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