You may want to think about using:

invocation.getStack().getContext().put(MAGIC_KEY,getStuff());

instead of:

invocation.getStack().set(MAGIC_KEY,getStuff());

For the sake of argument, I'm going to assume that MAGIC_KEY is set to the
String "magic".  The first example above makes #magic available in the Value
Stack's context, so you can simply use <s:property
value="%{#magic.gathering}"/> in your JSP to effectively give the same
results as a call to getStuff().getGathering().  Whereas the second example
changes the stack itself, which may be what's interfering with the other
interceptors.
  (*Chris*)

On Thu, May 20, 2010 at 8:18 AM, Andy Law <andy....@roslin.ed.ac.uk> wrote:

>
>
> RogerV wrote:
> >
> >
> >
> > Andy Law wrote:
> >>
> >> The pertinent code in the interceptor is reproduced below. It does what
> I
> >> expect it to do insofar as it sticks my "Stuff" object in a place that
> >> the JSP can retrieve it using the MAGIC_KEY string. However, if I
> >> configure my interceptor stack with this interceptor at the top, none of
> >> the other interceptors appear to fire. If I put this interceptor last in
> >> the stack, all of the others do seem to fire (well, the application
> >> works). Why should I need to put this after all the
> params-prepare-params
> >> stuff?
> >>
> >>     public String intercept(ActionInvocation invocation) throws
> >>             Exception {
> >>
> >>         if (this.getStuff() != null) {
> >>             ActionContext ic = invocation.getInvocationContext();
> >>             if (ic != null) {
> >>                 ValueStack vs = ic.getValueStack();
> >>                 if (vs != null) {
> >>                     vs.set(MAGIC_KEY, this.getStuff());
> >>                 }
> >>             }
> >>         }
> >>         return invocation.invoke();
> >>     }
> >>
> >> As always, any and all help/pointers gratefully accepted, particularly
> if
> >> I'm doing something stupid!</p>
> >>
> >>
> >
> > First of all, I'd load the config-browser plugin and check that the
> > interceptor stack your action is using is actually the stack that you
> > think it is. (BTDTGTTS)
> >
> > Secondly, I've never tried to poke the ValueStack directly, I've always
> > used Interceptors to load objects into my actions and then retrieved them
> > from there with the standard struts tags. What happens if you take all
> > your processing out leaving just "return invocation.invoke()" - does your
> > stack still fire?
> >
> > Regards
> >
>
>
> OK. Further investigation reveals the following:
>
> 1) The correct Interceptor stack *is* being configured and called (good
> call
> on the config-browser plugin, I hadn't seen that before. Thanks)
>
> 2) Regardless of the position of the troublesome Interceptor, the other
> Interceptors *do* fire
>
> 3) The key line is the "vs.set(MAGIC_KEY, this.getStuff());" line. Remove
> this and all is well (except the interceptor does not do anything). Leave
> it
> in and the action fails apparently because it never has the request
> parameters set.
>
> 4) That same line works "as expected" if the interceptor runs last and the
> object it injects *is* available in the JSPs.
>
>
> It is as if setting a value on the ValueStack like that somehow wipes out
> the Request parameters from the context.
>
> Obviously I have two possible workarounds but this is bugging me. I don't
> want to make my Actions know about the object being injected - this is not
> part of their logic. Also, I don't want to have an application with some
> "magic" order-related feature that I'll forget about in 6 months time. This
> *should* work but it doesn't and that's just wrong!
>
> Anyone more clues, anyone?
>
> Later,
>
> Andy
>
> --
> View this message in context:
> http://old.nabble.com/Interceptor-order-tp28597967p28622744.html
> Sent from the Struts - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
>

Reply via email to