Announcement Announcement Module
Collapse

JavaConfig forum decommissioned in favor of Core Container

As described at

http://static.springsource.org/sprin...fig/README.TXT

key features of the Spring JavaConfig project have been migrated into the core Spring Framework as of version 3.0.

Please see the Spring 3.0 documentation on @Configuration and @Bean support:

http://static.springsource.org/sprin...tml#beans-java

For any questions related to @Configuration classes and @Bean methods in Spring 3.0, please post in the dedicated 'Core Container' forum at

http://forum.springsource.org/forumdisplay.php?f=26
See more
See less
More on session scoped beans Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • More on session scoped beans

    I believe I'm encountering the same issue as presented here, towards the top, relating to session-scoped beans throwing the 'session not active' IllegalStateException. However, that discussion moved on towards different configuration issues, so I wanted to start a new thread to clarify my problem.

    I'm attempting to migrate our SJC Configurations to the M4 build (to use @Resource and @Autowired in favor of @ExternalBean). I have singleton beans referencing a session-scoped bean marked as a @ScopedProxy. When the servlet starts up and container is configured, the session-scoped bean throws the IllegalStateException, as there is no request on startup. These worked fine on the M3 release, but throw the exception on M4 and the nightly snapshots.

    Sample beans in question:
    Code:
    @Bean(scope = DefaultScopes.SESSION, destroyMethodName = "destroy", initMethodName = "init")
    @ScopedProxy(proxyTargetClass = false)
    public FileUploadProgressManager fileUploadProgressManager()
    {
        return new FileUploadProgressManagerImpl();
    }
    
    @Bean
    public FileUploadProgressService fileUploadProgressService()
    {
        return new FileUploadProgressServiceImpl(fileUploadProgressManager());
    }
    Tracing through, it seems that the ScopedProxyFactory that wraps the session-scoped bean also gets flagged as having a "session" scope in its generated BeanDefinition, which causes the exception when it tries to load it as a dependency for the singletons. That may be accurate, but if so, how do the proxies work with singleton beans?

    Nick Dresselhaus

  • #2
    Really seems like we have the same problem. I belive the solution shown in the other tread is only a workaround for the RichClient Solution. My Guess is that the Proxy is not working the same way as in a plain XML configuration.

    With the following applicationContext.xml I get no Problems:

    Code:
    <beans>
    <bean id="serviceBenutzerkonto" class="....BenutzerkontoServiceImpl" scope="session">
    	<aop:scoped-proxy proxy-target-class="false"/>
            <property name="userDao" ref="userDAO" />
    	<property name="lockingService" ref="serviceLocking" />
    	<property name="maxId" ref="maxIdDAO" />
    </bean>
    ...
    </beans>
    But with confiruration by the JavaConfig, I get the IllegalStateException as well. If I access the service later, everything works fine, but I get the warning at application start (And my guess is that the other problems would be solved as well).

    Code:
    <beans>
    <bean class="....AdminServiceConfig"/>
    
    	<bean class="org.springframework.config.java.process.ConfigurationPostProcessor"/>
    </beans>
    Code:
    @Configuration
    public abstract class AdminServiceConfig {
    	
    	@Bean(scope = DefaultScopes.SESSION)
    	@ScopedProxy(proxyTargetClass = false)
    	public BenutzerkontoServiceImpl serviceBenutzerkonto() {
    		BenutzerkontoServiceImpl service = new BenutzerkontoServiceImpl();
    		service.setLockingService(serviceLocking());
    		service.setMaxId(maxIdDAO());
    		service.setUserDao(userDAO());
    		service.setPasswordsDao(passwordsDAO());
    		return service;
    	}
    ...
    }

    Comment


    • #3
      Looks like there may be an issue here - if one of you would create a JIRA issue to this effect (jira.springframework.org) and ideally attach a simple maven-built webapp that reproduces the issue, I'll be able to address it quite quickly.

      Comment


      • #4
        I've created SJC-254 for the issue.

        Thanks for the assistance, Chris.

        Nick

        Comment


        • #5
          Resolved. You'll find the fix in the next nightly build.

          Comment


          • #6
            Just wanted to confirm that session scoped beans work fine for me now.

            Comment


            • #7
              Excellent! Thanks to both of you for helping to catch this issue.

              Comment

              Working...
              X