Hmm, perhaps there is a bug here, there seems to be an issue when the application is deployed as ROOT in a Tomcat instance, session information is lost and urls all end up with a jsessionid different for each request. If I revert back to the default sessionManager then a ROOT application works, the DefaultWebSession only seems to work when the application is deployed as a non root context path.
Are there any obvious reasons why this should be the case? Marcus. -----Original Message----- From: Marcus Bond [mailto:[email protected]] Sent: 15 June 2012 19:47 To: [email protected] Subject: RE: Subject.Builder Exception SessionContext Thanks Thilo, It is slightly different with Spring but didn’t take too long to figure out.. In case anyone else is interested you just set a DefaultWebSessionManager instance on the SecurityManager sessionManager property whereas otherwise you are stuck with the ServletContainerSessionManager which cannot be used without access to a HttpSession. Marcus. -----Original Message----- From: Thilo-Alexander Ginkel [mailto:[email protected]] Sent: 15 June 2012 18:09 To: [email protected] Subject: Re: Subject.Builder Exception SessionContext On Fri, Jun 15, 2012 at 4:50 PM, Marcus Bond <[email protected]> wrote: > I was following the example on the website in regard to subjects and > in particular creating a subject for use in executing a different > thread using “new Subject.Builder()..” and have been hitting the > exception > > java.lang.IllegalArgumentException: SessionContext must be an HTTP > compatible implementation. > > Same thing applies when I use WebSubject.Builder(). In fact the code > definitely shouldn’t use WebSubject anyway since this is in a service > layer component that has no awareness that it is running in a web app. > > I thought about using a separate security manager for this but then > read that only one security manager per application is recommended… > This kind of thing must have been solved before, any ideas please? Yep, see my post from yesterday ;-) http://shiro-user.582556.n2.nabble.com/Using-non-web-based-sessions-from-within-a-web-application-s-background-jobs-td7577505.html Regards, Thilo
