RE: [OS-webwork] XWork Interceptors
You could simply add a Frequently Asked Question for this.
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()).ge
tTypeConverter();
OgnlUtil.setProperties(ActionContext.getContext().getParameters(),
invocation.getAction(), typeConverter);
return invocation.next();
}
}
I'm not so sure about this case. In this case, you need to map the
interceptor to your classes, rather than it being the default. Yes, we
can work on packages and interceptor defaults, but the fact remains that
if you leave one line out of your xwork.xml, all of a sudden request
params don't get set on your actions which equals lots of confused
emails to the list.
---
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
--
Michael Blake Day
Artistry Studios
mobile: 770.480.1547
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork Interceptors
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.valuessuccess, 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
Re: [OS-webwork] XWork Interceptors
Quoting Rickard Öberg [EMAIL PROTECTED]: Hani Suleiman wrote: Well, we're not talking about writing a tx system here, just providing the calls to begin/commit/rollback. And that's definitely a good idea to put here, especially if you're doing a straight servlets/db application, i.e. no EJB's to do the tx demarcation. And even if you *do* use EJB, sometimes it's better to do tx demarcation at this level instead of introducing a new session bean just to be able to do tx mgmt for a set of operations. Sure, however, please do keep in mind that many people do choose to use EJB's for the tx stuff. Session beans really are great for that kind of thing. I realise that you and others have much against EJBs, and that's fair enough, but I was just voicing the sentiment that I don't want xwork to become a framework that aims to replace EJBs. Hani --- 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
Re: [OS-webwork] XWork Interceptors
Hani Suleiman wrote: Sure, however, please do keep in mind that many people do choose to use EJB's for the tx stuff. Session beans really are great for that kind of thing. I realise that you and others have much against EJBs, and that's fair enough, but I was just voicing the sentiment that I don't want xwork to become a framework that aims to replace EJBs. For those who want to use EJB's to do the tx demaraction, you'd simply remove the tx interceptor. /Rickard --- 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
Re: [OS-webwork] XWork Interceptors
For those who want to use EJB's to do the tx demaraction, you'd simply remove the tx interceptor. Or, another way to put what Rickard said is: For those who don't want to use EJB's to do the tx demarcation, you'd simply add the tx interceptor. ;) --- 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
Re: [OS-webwork] XWork Interceptors
No, of course not. Transactions are just a good base case because they are a type of interceptor that works on both sides of the action (before and after) and behavior can change based on possible configurations, changes in the action contex, etc. -Pat - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 10, 2003 2:37 AM Subject: Re: [OS-webwork] XWork Interceptors Quoting Rickard Öberg [EMAIL PROTECTED]: Hani Suleiman wrote: Well, we're not talking about writing a tx system here, just providing the calls to begin/commit/rollback. And that's definitely a good idea to put here, especially if you're doing a straight servlets/db application, i.e. no EJB's to do the tx demarcation. And even if you *do* use EJB, sometimes it's better to do tx demarcation at this level instead of introducing a new session bean just to be able to do tx mgmt for a set of operations. Sure, however, please do keep in mind that many people do choose to use EJB's for the tx stuff. Session beans really are great for that kind of thing. I realise that you and others have much against EJBs, and that's fair enough, but I was just voicing the sentiment that I don't want xwork to become a framework that aims to replace EJBs. Hani --- 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
Re: [OS-webwork] XWork Interceptors
For those who want to use EJB's to do the tx demaraction, you'd simply remove the tx interceptor. You mean not add it, I hope. The basic configuration should imho be as clean as possible. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- 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
RE: [OS-webwork] XWork Interceptors
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()).ge
tTypeConverter();
OgnlUtil.setProperties(ActionContext.getContext().getParameters(),
invocation.getAction(), typeConverter);
return invocation.next();
}
}
I'm not so sure about this case. In this case, you need to map the
interceptor to your classes, rather than it being the default. Yes, we
can work on packages and interceptor defaults, but the fact remains that
if you leave one line out of your xwork.xml, all of a sudden request
params don't get set on your actions which equals lots of confused
emails to the list.
---
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
Re: [OS-webwork] XWork Interceptors
Typo. Rickard Öberg wrote: When configuring actions you don't typically specify individual actions, ...individual interceptors, --- 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
Re: [OS-webwork] XWork Interceptors
I have to say, I really do think that adding tx on this level is a bad idea. For one thing, webwork is NOT a tx system, whatever it talks to should provide whatever tx support you require. Reinventing the wheel by handling the tx on this level seemsa waste of effort (vendors have already spent years getting their tx impls to work very nicely). To my mind (I'll admit I didnt read all the previous emails about interceptors in great detail, so I might be repeating old/known/wrong stuff), interceptors are pretty much like filters. An interceptor would choose what to intercept, then have access to context and whatnot to adds its own stuff. It can choose to then keep passing the request, or bail out. Similarly, an interceptor can be applied post-action. Quoting Patrick Lightbody [EMAIL PROTECTED]: 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.valuessuccess, 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
RE: [OS-webwork] XWork Interceptors
As for intercepting transactions, I would say have a key that is set in the context which tells the after() part of the Tx interceptor what to do. Kind of like setting rollbackOnly on a UserTransaction. Assume that the transaction should be committed unless an exception is caught or rollbackOnly is set on the ActionContext. -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.valuessuccess, 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
RE: [OS-webwork] XWork Interceptors
Well, for a different example, how about setting up a Hibernate Session and then closing it on the way out? Then Hibernate can manage your transactions. -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 10:35 AM To: [EMAIL PROTECTED]; Patrick Lightbody Cc: os-ww Subject: Re: [OS-webwork] XWork Interceptors I have to say, I really do think that adding tx on this level is a bad idea. For one thing, webwork is NOT a tx system, whatever it talks to should provide whatever tx support you require. Reinventing the wheel by handling the tx on this level seemsa waste of effort (vendors have already spent years getting their tx impls to work very nicely). To my mind (I'll admit I didnt read all the previous emails about interceptors in great detail, so I might be repeating old/known/wrong stuff), interceptors are pretty much like filters. An interceptor would choose what to intercept, then have access to context and whatnot to adds its own stuff. It can choose to then keep passing the request, or bail out. Similarly, an interceptor can be applied post-action. Quoting Patrick Lightbody [EMAIL PROTECTED]: 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.valuessuccess, 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 --- 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
Re: [OS-webwork] XWork Interceptors
One more thought... maybe the initialization parameters should become a
standard interceptor as well. I believe rickard had suggested this.
-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=foo17/param
/action-params
results
result name=success type=chain
result-params
param name=actionNameBar/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.valuessuccess, 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
