Regarding this issue - and considering any interceptor, not just the
ExecAndWaitInterceptor:
1) My issue was, in fact, that I was accessing the request/session
scoped bean in my init method. The init method was being called at app
startup, where no such context exists
2) If we remove that access, you can use the request/session scoped
bean.
3) You can also get the meaning with Spring's ApplicationContext inside
the intercept() method, with the call context.getBean("myBean");
As me and Lukasz were discussing this, we realised the init() method of
the interceptor is only being called at app startup - even if you define
it with, say, a prototype scope in spring. This means that apparently
Struts disregards spring's scope for interceptors, which has thread
safety implications (and you might be better off using the approach in
3) ).
Miguel
On Tue, 2012-05-15 at 09:00 +0200, Łukasz Lenart wrote:
> What I mean is that injecting something in ExecAndWaitInterceptor
> which has brought scope can rise concurrency issue because the same
> bean can be used in two different threads (ExecAndWaitInterceptor
> thread and request thread). I would rather pack whatever is needed by
> ExecAndWaitInterceptor and pass to it as a value object and inject
> just stateless services.
>
> That's what I mean by repackaging - to have my own context (a map of
> values, a value bean, etc) that will be passed to
> ExecAndWaitInterceptor and used by it in separation from other
> threads.
>
> And interceptors are singletons per package (<package/> tag in
> struts.xml) and even worst ExecAndWaitInterceptor creates its own
> thread ;-)
>
>
> Regards
