Re: Using Spring proxied Session Beans with the ExecAndWaitInterceptor

[wild_oscar <mi...@almeida.at>]

Hi, 

I've got the exact same problem as this user. Injecting either request or
session scoped beans in an interceptor yields the error
"org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'scopedTarget.diagnosticContext': Scope 'session' is not
active for the current thread; consider defining a scoped proxy for this
bean if you intend to refer to it from a singleton;..."

My setup is fairly similar to the Roger's. Injecting the same request scoped
bean onto an action works as expected, so the problem is not in the
configuration (the ContextLoaderListener and RequestContextListener are
defined in the web.xml).


Do you know how to inject the beans onto the interceptor (which is also
being managed through Spring)?

Cheers,

Miguel Almeida

roger wrote
> 
> Hi
> 
> I've been experimenting with using Springs scoped Proxy beans to handle my
> session bean management rather than using the more normal SessionAware
> interface, 
> 
> <bean id = "diagnosticContext"
> class="com.blackbox.genesis.services.diagnostics.DiagnosticContext"
> 			scope="session">
> 			<aop:scoped-proxy/>
> 			</bean>
> 
> and injecting my session beans into the application where required. Up
> until now it's been working well. However, I've hit a problem with trying
> to access the session in an action that runs under the
> ExecAndWaitInterceptor and the action crashes with;
> 
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'scopedTarget.diagnosticContext': Scope 'session' is not
> active for the current thread; consider defining a scoped proxy for this
> bean if you intend to refer to it from a singleton; nested exception is
> java.lang.IllegalStateException: No thread-bound request found: Are you
> referring to request attributes outside of an actual web request, or
> processing a request outside of the originally receiving thread? If you
> are actually operating within a web request and still receive this
> message, your code is probably running outside of
> DispatcherServlet/DispatcherPortlet: In this case, use
> RequestContextListener or RequestContextFilter to expose the current
> request. 
> 
> I have the RequestContextListener configured in my web-xml and the action
> that runs under the ExecAndWaitInterceptor is created through Spring using
> the @Controller annotation with @Scope("prototype"). I'm guessing that the
> problem is that the ExecAndWait interceptor creates it's own thread under
> which the action runs, so when it accesses the proxy bean, the proxy bean
> cannot see the "session"
> 
> I can't use SessionAware here as the Spring documentation specifically
> states that Spring stores the session beans in a location that is tied to
> the session object - not that it stores the beans actually in the session
> object itself - so I'm not sure that I would be able to access the spring
> proxy bean reliably.
> 
> While trying to find out more, I came across references in the 2.0 and 2.1
> documentation to the 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 Spring proxied session beans working with the
> ExecAndWaitInterceptor?
> 


--
View this message in context: http://struts.1045723.n5.nabble.com/Using-Spring-proxied-Session-Beans-with-the-ExecAndWaitInterceptor-tp3472886p5709358.html
Sent from the Struts - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Using Spring proxied Session Beans with the ExecAndWaitInterceptor

[Miguel Almeida <mi...@almeida.at>]

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

Re: Using Spring proxied Session Beans with the ExecAndWaitInterceptor

[Łukasz Lenart <lu...@googlemail.com>]

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
-- 
Łukasz http://www.lenart.org.pl/
mobile +48 606 323 122, office +27 11 0838747
Warszawa JUG conference - Confitura http://confitura.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Using Spring proxied Session Beans with the ExecAndWaitInterceptor

[Miguel Almeida <mi...@almeida.at>]

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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Using Spring proxied Session Beans with the ExecAndWaitInterceptor

[Łukasz Lenart <lu...@googlemail.com>]

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/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org