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 singleton (in spring beans terms) to the entire
application.
As for the repackaging you suggest, I'm not sure I follow your
suggestion. Do you mean getting the ActionContext in the interceptor to
get to the HttpSession and HttpRequest and populate the variable from there?
I ask you this due to the motivation behind the request scoped bean in
my case: I basically want to populate it in an interceptor so it is
available elsewhere (on an hibernate interceptor/event listener - don't
let the name trick you, this has nothing to do with Struts interceptors.
It also doesn't know anything about http sessions or requests and should
really be http agnostic).
Could you clear me up on you meant by your approach?
Thanks,
Miguel Almeida
On 05/14/2012 08:11 PM, Łukasz Lenart wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
