Struts Interceptors

["Biesbrock, Kevin" <Bi...@aoins.com>]

I'm not really sure how to ask this question, so please bear with me.
 
Requirement:
The system has several functions which a typical user can perform.  The
user selects a function and the appropriate action is executed.  If that
action implements myObjectAware, myObjectInterceptor retrieves myObject
(which is based on dates).  This is all working correctly.
 
The Problem:
An administrative user has the option to override these
function/date-based selectors by providing myObjectId as a parameter in
the url (e.g., ?myObjectId=1).  While watching the logs, the
myObjectInterceptor is executed the first time with myObjectId=1.  This
is where my understanding becomes a little cloudy.  I believe after the
interceptor is executed initially (and the rest of the interceptor stack
is executed), the action is executed, and then the interceptors are
executed in reverse order.  This is what appears to be happening and the
second time my interceptor is executed, myObjectid=null (i.e.,
myObjectId is not a parameter on the request).
 
I think I understand why this happens...because in the response (i.e.,
the result), the myObjectId is not being carried over from the initial
request.
 
Because myObjectId=null, myObjectInterceptor believes that it should
resort to the function/date-based selection of myObject; thereby
effectively ignoring the administrative user's request and selecting
myObject by function/date.
 
Question:
How should I be handling the second execution of myObjectInterceptor?
1. Is there a way to ignore the second execution of myObjectInterceptor?
2. Should I create a public property on *all of my actions* to store
myObjectId?
3. Some much simpler way I'm overlooking?
 
Hopefully this is enough info to at least get a conversation started.
 
I appreciate your time in reading this.
 
Sincerely,
Beez

RE: Struts Interceptors

["Biesbrock, Kevin" <Bi...@aoins.com>]

On Friday, December 10, 2010 2:33 PM, Dave Newton wrote:

> if you want to do something before rendered you need to implement
PreResultListener.

I will keep this in mind.

As far as the redirect issue, I just need to rework my actions a bit, I
guess.  I appreciate your wealth of knowledge, Dave.

Sincerely,
Beez


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Struts Interceptors

[Dave Newton <da...@gmail.com>]

On Fri, Dec 10, 2010 at 2:23 PM, Biesbrock, Kevin wrote:

> Ah.  So is the idea that you *could* have logic in an interceptor that
> executes after the action by adding logic after invocation.invoke()?
>

Sure, like closing a Hibernate session, for example.

The caveat (to me, at least) is that the result has already been rendered by
the time you return from the "invoke" call; if you want to do something
before rendered you need to implement PreResultListener.

Dave

RE: Struts Interceptors

["Biesbrock, Kevin" <Bi...@aoins.com>]

Ah.  So is the idea that you *could* have logic in an interceptor that
executes after the action by adding logic after invocation.invoke()?
invocation.invoke is the method that executes the next interceptor,
correct?

Frick.  A redirect is exactly what is causing my issue.

Thank you, kindly!

Beez
r 5347 

-----Original Message-----
From: Dave Newton [mailto:davelnewton@gmail.com] 
Sent: Friday, December 10, 2010 2:15 PM
To: Struts Users Mailing List
Subject: Re: Struts Interceptors

Interceptors don't "execute in reverse order", they're each a "wrapper"
around the next interceptor's execution, and eventually, the action
itself.

If the interceptor is firing twice there's been to requests, which could
be a result of a redirect.

Dave

On Fri, Dec 10, 2010 at 1:50 PM, Biesbrock, Kevin
<Biesbrock.Kevin@aoins.com
> wrote:

> I'm not really sure how to ask this question, so please bear with me.
>
> Requirement:
> The system has several functions which a typical user can perform.  
> The user selects a function and the appropriate action is executed.  
> If that action implements myObjectAware, myObjectInterceptor retrieves

> myObject (which is based on dates).  This is all working correctly.
>
> The Problem:
> An administrative user has the option to override these 
> function/date-based selectors by providing myObjectId as a parameter 
> in the url (e.g., ?myObjectId=1).  While watching the logs, the 
> myObjectInterceptor is executed the first time with myObjectId=1.  
> This is where my understanding becomes a little cloudy.  I believe 
> after the interceptor is executed initially (and the rest of the 
> interceptor stack is executed), the action is executed, and then the 
> interceptors are executed in reverse order.  This is what appears to 
> be happening and the second time my interceptor is executed, 
> myObjectid=null (i.e., myObjectId is not a parameter on the request).
>
> I think I understand why this happens...because in the response (i.e.,

> the result), the myObjectId is not being carried over from the initial

> request.
>
> Because myObjectId=null, myObjectInterceptor believes that it should 
> resort to the function/date-based selection of myObject; thereby 
> effectively ignoring the administrative user's request and selecting 
> myObject by function/date.
>
> Question:
> How should I be handling the second execution of myObjectInterceptor?
> 1. Is there a way to ignore the second execution of
myObjectInterceptor?
> 2. Should I create a public property on *all of my actions* to store 
> myObjectId?
> 3. Some much simpler way I'm overlooking?
>
> Hopefully this is enough info to at least get a conversation started.
>
> I appreciate your time in reading this.
>
> Sincerely,
> Beez
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Struts Interceptors

[Dave Newton <da...@gmail.com>]

Interceptors don't "execute in reverse order", they're each a "wrapper"
around the next interceptor's execution, and eventually, the action itself.

If the interceptor is firing twice there's been to requests, which could be
a result of a redirect.

Dave

On Fri, Dec 10, 2010 at 1:50 PM, Biesbrock, Kevin <Biesbrock.Kevin@aoins.com
> wrote:

> I'm not really sure how to ask this question, so please bear with me.
>
> Requirement:
> The system has several functions which a typical user can perform.  The
> user selects a function and the appropriate action is executed.  If that
> action implements myObjectAware, myObjectInterceptor retrieves myObject
> (which is based on dates).  This is all working correctly.
>
> The Problem:
> An administrative user has the option to override these
> function/date-based selectors by providing myObjectId as a parameter in
> the url (e.g., ?myObjectId=1).  While watching the logs, the
> myObjectInterceptor is executed the first time with myObjectId=1.  This
> is where my understanding becomes a little cloudy.  I believe after the
> interceptor is executed initially (and the rest of the interceptor stack
> is executed), the action is executed, and then the interceptors are
> executed in reverse order.  This is what appears to be happening and the
> second time my interceptor is executed, myObjectid=null (i.e.,
> myObjectId is not a parameter on the request).
>
> I think I understand why this happens...because in the response (i.e.,
> the result), the myObjectId is not being carried over from the initial
> request.
>
> Because myObjectId=null, myObjectInterceptor believes that it should
> resort to the function/date-based selection of myObject; thereby
> effectively ignoring the administrative user's request and selecting
> myObject by function/date.
>
> Question:
> How should I be handling the second execution of myObjectInterceptor?
> 1. Is there a way to ignore the second execution of myObjectInterceptor?
> 2. Should I create a public property on *all of my actions* to store
> myObjectId?
> 3. Some much simpler way I'm overlooking?
>
> Hopefully this is enough info to at least get a conversation started.
>
> I appreciate your time in reading this.
>
> Sincerely,
> Beez
>