>> Are you configuring Shiro in .ini or a spring.xml file? There is
>> usually no need to reference or use a SecurityManager Factory
>> implementation directly...
>
> I'm 'configuring' shiro with the .ini - I dont know how its done in spring.
Ah, ok. Yep, we definitely need a Spring example that does not
require Ini. Ini is a 'lowest common denominator' configuration
mechanism for all environments. Spring has a much richer object
configuration model, so if you're using Spring, you should definitely
configure Shiro that way.
> when I created this I wanted to keep the threadlocal in here too, but I
> couldnt find a way to get a reference to the instantiation in order to set
> it.
Gotcha. When using Spring configuration, you can naturally reference
your SessionDAO by normal dependency injection.
> I'm configuring 'the use' of Shiro using spring - eg:
>
> <bean id="securityManagerFactoryBean"
> class="org.apache.shiro.config.IniSecurityManagerFactory"/>
...
> <bean id="propertiesRealm"
> class="org.apache.shiro.realm.text.PropertiesRealm"/>
Yep, we really need a standalone Spring example ;) Please create the
Jira issue for this if you haven't already.
I'd use the newer IniRealm if you're using simple text-based account
config for now - it essentially replaces the properties realm as it is
a little cleaner and easier to read.
Try this for your Spring config:
<bean id="securityManager" class="org.apache.shiro.mgt.DefaultSecurityManager">
<property name="realm" ref="iniRealm"/>
</bean>
<!-- Assumes the default 'classpath:shiro.ini' location. Or you can change the
location with the 'resourcePath' property: -->
<bean id="iniRealm" class="org.apache.shiro.realm.text.IniRealm"
init-method="init"/>
<bean id="securityManagerStaticSingletonInitializer"
class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
<property name="targetClass" value="org.apache.shiro.SecurityUtils"/>
<property name="targetMethod"><value>setSecurityManager</value></property>
<property name="arguments">
<list>
<ref bean="securityManager" />
</list>
</property>
</bean>
> not sure, I'm just surprised at how much work the already retrieved session
> has to do to fetch a simple attribute value, as I expected it to be a direct
> ref to a map.
I see. We're getting deep into implementation details here, but this
might clarify some things: The Session reference held by the Subject
instance is not the actual Session. It is itself a proxy back to the
SecurityManager which in turn delegates calls to the SessionManager.
The SessionManager is the only thing that has direct reference to the
raw Session model objects. This is done for a number of reasons,
including transaction management during session operations, security
(only the SecurityManager/SessionManager implementations have the
final say as to how things happen w/ Sessions exactly), and to manage
visibility (only the SessionDAO/SessionManager manipulate Session
state per appropriate management logic). The internal Session objects
do have an immediate reference to their attribute Map.
> one quick, unrelated, very small change that could be made with the
> DefaultCacheManager would be to swap the HashMap for a ConcurrentHashMap
Yep, you're absolutely right - this is a much better approach. The
existing implementation is really a remnant of pre JDK 1.5 days.
Shiro 1.0 will be 1.5+ compliant, so we can fix this now. Thanks for
bringing this up!
HTH,
Les
