Problems with URL handling to scoped controllers [SPR-7456]

[spring-projects-issues]

Alexander Borovsky opened SPR-7456 and commented

1. Info (or more detail) level logging
2. We have URL mapping, e.g.

<bean id="contentUrlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
  <property name="alwaysUseFullPath" value="true"/>
  <property name="mappings">
    <props>
      <prop key="/action.do">actionController</prop>
    </props>
  </property>
</bean>

3. We have scoped controller, e.g

<bean id="actionController" class="my.ActionController" scope="session">
  <aop:scoped-proxy/>
</bean>

When we try to start application, we get following exception:

Caused by: org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'scopedTarget.actionController': 
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.
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:339)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190)
        at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33)
        at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:653)
        at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:604)
        at com.vi.portal.whatcanido.WhatCanIDoController$$EnhancerByCGLIB$$5e8730ba.toString(<generated>)
        at java.lang.String.valueOf(String.java:2826)
        at java.lang.StringBuilder.append(StringBuilder.java:115)
        at org.springframework.web.servlet.handler.AbstractUrlHandlerMapping.registerHandler(AbstractUrlHandlerMapping.java:411)
        at org.springframework.web.servlet.handler.SimpleUrlHandlerMapping.registerHandlers(SimpleUrlHandlerMapping.java:129)

It occurs because AbstractUrlHandlerMapping.registerHandler logs controller mapping:

if (logger.isInfoEnabled()) {
	logger.info("Mapped URL path [" + urlPath + "] onto handler [" + resolvedHandler + "]");
}

and resolveHandler.toString() is executed, this requires proxy to create underline scoped bean, but it can't create it without request.

PS. the same problem can occurs in different places of this function or in other functions.

---

Affects: 3.0.3

[spring-projects-issues]

Juergen Hoeller commented

Is there a specific reason why you are using a scoped proxy for that controller? You could also simply declare it as plain scope="session", i.e. without aop:scoped-proxy. The HandlerMapping would then obtain the current controller instance for every request; it is explicitly capable of such on-demand retrieval.

That said, it's of course generally not desirable to have a toString() call failing because the target bean is not in scope. I'll see what I can do about this.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid toString() is expected to be a regular bean operation here, delegated to the actual target object. However, for Spring 3.0.4, I've refined AbstractUrlHandlerMapping and several other places to not log the handler instance anymore but rather just the handler type. This should work fine with scoped-proxy controllers now, even if I nevertheless recommend the use of raw scoped controllers instead.

FYI, Spring 3.0.4 also features revised last-modified handling in DispatcherServlet, avoiding retrieval failures for scoped controllers in getLastModified. This didn't lead to an actual problem before (except when trying to use the old LastModified interface with a scoped controller) but showed up as a nasty stacktrace in the debug log.

Juergen