struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miguel Almeida <>
Subject Re: Using Spring proxied Session Beans with the ExecAndWaitInterceptor
Date Wed, 16 May 2012 09:59:21 GMT
Regarding this issue - and considering any interceptor, not just the

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
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) ).


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message