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,
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 pa
Following up on your suggestion, Lukasz: is concurrency an issue even if
you scope the interceptor itself as prototype (or request) ?
I was under the impression you could scope the interceptors like this
(removing concurrency issues), but actually the previous issue makes me
wonder if they're
I think it's better to repackage what you need and pass as a context
variables instead inject session aware beans. It can produce
concurrency issues.
Regards
--
Łukasz http://www.lenart.org.pl/
mobile +48 606 323 122, office +27 11 0838747
Warszawa JUG conference - Confitura http://confitura.pl/
SessionContextAutowiringInterceptor which by it's
> name seems a likely thing to investigate, but this isn't in Struts 2.2.1
> anymore - was it redundant or has the functionality moved into another
> interceptor?
>
> Has anyone managed to get S
ExecAndWaitInterceptor?
--
View this message in context:
http://old.nabble.com/Using-Spring-proxied-Session-Beans-with-the-ExecAndWaitInterceptor-tp30986350p30986350.html
Sent from the Struts - User mailing list archive at Nabble.com.
---
6 matches
Mail list logo