On Mon, Dec 21, 2009 at 3:36 AM, Jason Eacott <[email protected]> wrote: > ok, > I did as you described, something like this in conjunction with a simple > sessionDao as you described: > > //gets or creates a session with the given sessionId > public Subject getSubjectBySessionId(String sessionId){ > Subject subject =null; > try { > newSessionId.set(sessionId); > subject = new > Subject.Builder(securityManager).sessionId(sessionId).buildSubject(); > subject.getSession(true); > } > } finally { > newSessionId.remove(); > } > return subject; > } > > and it works. thank you.
Glad to hear it. > it did take me a while to figure out what was happening though, and to > realise that the session isn't created until subject.getSession(true) is > called (or something else touches the session) so when I fist did this I > didnt have the getSession(true) step, so it failed. Yes, due to the fact that sessions naturally consume resources (i.e. memory), Shiro will only create a session if necessary. By default, once a user is logged in, a session is created for them as well since Shiro will store Subject information (principals, etc) in the session. This is also to retain the behavior that people are accustomed to with HttpSessions. > I spent some time trying to figure out if I could either access my > XmppMemorySessionDAO via the api, or inject a pre instantiated one somewhere > but it seems not possible? > > it also took me a little while to find & figure out how to instantiate > everything with the new config factory. 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'd like to ask that the other examples be updated (not just the quickstart) > to reflect the changes. Please create a Jira issue for this for the 1.0 release so we don't forget about it. I think this is a good idea, but if it is not in Jira, it won't get done (easy to slip through the cracks when so many other things are on the mind). > I'd also like to suggest a standalone spring example so that its easy to see > & duplicate exactly what needs to be created for folk not using either of > the spring entrypoints offered. Could you elaborate on this a little more? Or maybe clarify in the Jira issue? What entry points do you mean, and if they are not sufficient, what more would you like supported? I use Spring all the time with Shiro, so if there is something better that we can do, I'd be very happy to work on this since it would naturally benefit me too ;) > one last thing I noted, there seem to be a lot of method calls made for any > interaction with the api. for example, whenever an attribute is got/put from > an already aquired session, the internal session reference seems to be > rediscovered quite a lot. Yes - with the exception of the simple memory-only Realms (IniRealm, PropertiesRealm, SimpleAccountRealm), Shiro's architecture is 100% stateless. It relies on caching (either done via a CacheManager/Cache instances) or the underlying SessionDAO implementation or Transaction mechansims to perform memory and/or thread-local caching themselves to ensure that frequent Session lookups will be efficient. If you think this should be different (say, Shiro does thread-local Session caching as well), please feel free to open a Jira improvement issue and we can talk about strategies for this on the dev list. Best, Les
