To be clear, this is what's happening:
1) Request is made to /foobar/foo, which triggers FooAction.foo().
2) The interceptor begins to process this request.
3) Another request is made concurently to /foobar/bar, which triggers
FooAction.bar().
4) The interceptor from step 2 does ai.invokeActionOnly(). Now, when it
compares action.toString() to ai.getAction().toString(), the results are
different.
Is this the expected behavior?
On Mon, Nov 4, 2013 at 4:14 AM, Martin Gainty <mgai...@hotmail.com> wrote:
>
>
>
>
>
> > Date: Mon, 4 Nov 2013 02:49:12 +0500
> > Subject: Re: Struts seems to reset the action instance while its still
> in interceptor
> > From: ali.rac...@gmail.com
> > To: user@struts.apache.org
> >
> > Hopefully I am incorrect, however the following lines in my interceptor's
> > intercept method:
> >
> > action = ai.getAction();
> > String result = ai.invoke();
> > logger.debug("Orig action : " + action.toString() +" , now : " +
> > ai.getAction().toString() );
> >
> > Do produce two different toString() codes for the original action and the
> > new ai.getAction(). Is there any scenario in which this could happen?
> >
> > I'm serving two actions from the same class, i.e mysite/foo is being
> served
> > by FooAction.foo(),
> MG>action.class //1st instance
>
> and mysite/bar is being served by FooAction.bar().
> MG>action.class //2nd instance
>
> MG>Unless you coded FooAction to be a singleton each request will produce
> a unique Instance Signature
> MG>action.toString().equalsIgnoreCase(ai.getAction().toString()) would
> always return false
>
> So
> > in both cases, the same class is serving two actions.
> MF>JVM references the unique class instance produced by the request
> MG>(not the class)
>
> Could this have any
> > bearing on why action.toString() and ai.getAction.toString() are
> producing
> > different codes?
> MG>2 difference requests..2 different action class signatures
> >
> >
> > On Mon, Nov 4, 2013 at 2:18 AM, Dave Newton <davelnew...@gmail.com>
> wrote:
> >
> > > You are incorrect. Actions are instantiated per-request. Other than
> that,
> > > you will need to provide a working example that exhibits the incorrect
> > > behavior.
> > > On Nov 3, 2013 12:57 PM, "Ali Akhtar" <ali.rac...@gmail.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > It seems that if I have two concurrent requests being made to the
> same
> > > > action, e.g mysite.com/fooAction, then struts resets the first
> action's
> > > > instance while that instance may still be in the interceptor.
> > > >
> > > > E.g, if I have the following code in my interceptor:
> > > >
> > > > action = ai.getAction();
> > > > String result = ai.invoke();
> > > > logger.debug("Orig action : " + action.toString() +" , now : " +
> > > > ai.getAction().toString() );
> > > >
> > > > And if I make two concurrent requests to the same action (e.g using
> > > > javascript), then the line:
> > > >
> > > > logger.debug("Orig action : " + action.toString() +" , now : " +
> > > > ai.getAction().toString() );
> > > >
> > > > will sometimes produce two different `toString()` codes, showing
> that the
> > > > original action was in a different instance than the last action.
> > > >
> > > > This is a big problem, because now, if I had any code in the
> interceptor,
> > > > which was setting certain things on my action, e.g doing the
> following:
> > > >
> > > > MyAction action = (MyAction) ai.getAction();
> > > > Auth auth = new Auth ( action.getSession() );
> > > > action.setAuth(auth);
> > > > action.setCookiesMap( Util.getAllCookies() );
> > > > String result = ai.invoke();
> > > >
> > > > then there is no guarantee that all those things which I've set on my
> > > > action are in fact going to be passed to the correct instance. I.e,
> when
> > > > `ai.invoke()` is called, it may in fact call a completely different
> > > > instance of the action, which has different cookies or other data
> set on
> > > > it. This could result in different users being given access to each
> > > other's
> > > > data.
> > > >
> > > > Am I correct in all of this? If so, is there a solution to this
> problem?
> > > > Because this seems to completely defeat the purpose of interceptors.
> > > >
> > > > Thanks in advance.
> > > >
> > >
>
>
