Actually, the more that I think about it, I think wholesale removing the property would be a good idea - or at least make it a read-only/'computed' property. We'd just need to update the documentation and make a backwards-incompatibility note, showing how to achieve the same thing with injection (even in INI it is easy to do this).
On Mon, May 16, 2011 at 5:46 PM, Les Hazlewood <[email protected]> wrote: > Hi Jason, > > The 'sessionMode' property was intended to be a convenience trigger to > set up an appropriate SessionManager automatically (for example, if > configuring with more primitive mechanisms, like with INI). > > Since you're explicitly configuring a sessionManager directly, you > shouldn't need to set it. I see however that a very small amount of > logic (isHttpSessionMode()) is dependent upon it being set correctly, > which is unfortunate. > > There are two ways this can probably be solved: > > 1. The value is automatically set to 'native' if injecting a > NativeSessionManager instance (which DefaultWebSessionManager > implements). > 2. A WebSecurityManagerFactoryBean implementation could be created > for Spring to 'cache' all of the configured settings until building is > necessary, at which time those things can be set properly. > > Maybe both would be a good idea. > > Can you please open a Jira issue for this? I would consider this a > bug for sure. It would be a fairly easy fix though... > > Thanks, > > Les > > On Mon, May 16, 2011 at 4:41 PM, jhericks <[email protected]> wrote: >> I just got done working through an issue trying to get single sign-on working >> with EhCacheManager, following some examples I found elsewhere on the >> mailing list (except I was using Spring configuration). It wasn't working >> for me at first with this: >> >> >> <bean id="securityManager" >> class="org.apache.shiro.web.mgt.DefaultWebSecurityManager"> >> <property name="realm" ref="factorlabRealm" /> >> <property name="subjectFactory" ref="factorlabSubjectFactory" >> /> >> <property name="cacheManager" ref="ssoCacheManager" /> >> <property name="sessionManager" ref="sessionManager" /> >> <property name="sessionMode" value="native" /> >> </bean> >> >> >> After lots of debugging, I got it to work with this: >> >> >> <bean id="securityManager" >> class="org.apache.shiro.web.mgt.DefaultWebSecurityManager"> >> <property name="sessionMode" value="native" /> >> <property name="realm" ref="factorlabRealm" /> >> <property name="subjectFactory" ref="factorlabSubjectFactory" >> /> >> <property name="cacheManager" ref="ssoCacheManager" /> >> <property name="sessionManager" ref="sessionManager" /> >> </bean> >> >> >> The difference is moving the sessionMode to earlier in the property list, >> because the setter for sessionMode was replacing my configured >> sessionManager with a new DefaultWebSessionManager. >> >> This seems pretty fragile. Is it a bug? This was with version 1.0.0. Has >> it been addressed in later versions? >> >> -- >> View this message in context: >> http://shiro-user.582556.n2.nabble.com/Order-of-setting-sessionMode-matters-tp6371025p6371025.html >> Sent from the Shiro User mailing list archive at Nabble.com.
