I ran into a problem when using Shiro in a webapplication running on a JEE7-container (Wildfly 8). I'm not sure if this is an issue of the application server or Shiro. You can find the ongoing discussion for Wildfly under https://community.jboss.org/thread/239310
For those who do not want to read the forum-thread: If I use the webinterface of my application, Shiro wraps the request because of the registered filter and stores some information via the class ThreadContext in an InheritableThreadLocal variable. At some point, the application server may decide to spawn new threads (e.g. to work on asynchronous EJB-methods), if they have not been created and pooled so far. Since Shiro uses an InheritableThreadLocal variable instead of a ThreadLocal one, this child process inherits the security-related information from the parent thread. After the web request is finished, Shiro removes it's information from the InheritableThreadLocal variable of the current thread, but of course cannot remove it from the spawned one. Since the child-thread is pooled, it may be used later for another task but still contains the stored security-information from the initial web request. So the question is: why uses Shiro InheritableThreadLocal instead of ThreadLocal (as written in the Wildfly-forum, it is used since August 2007)? Is there any chance to get rid of this problem? Is this a Shrio issue? -- View this message in context: http://shiro-user.582556.n2.nabble.com/Inheritance-of-Security-Context-causes-problems-in-EJB-container-tp7579859.html Sent from the Shiro User mailing list archive at Nabble.com.
