https://issues.apache.org/bugzilla/show_bug.cgi?id=56989
--- Comment #2 from Mel Martinez <m.marti...@ll.mit.edu> --- Hi Konstantin, Thanks for your quick response on this topic. I will try to find the time to throw together a pair of sample web apps that will reproduce the problem (I cannot provide our actual project code). That may not happen for a day or two. I am not expecting support at all and I would hope that would be clear from the details I have provided. I have a workaround for the problem already as indicated in my report. I am posting this bug report so that the Tomcat committers are aware that they have a very serious bug in the class loader implementation. The use of a ThreadLocal by the Spring code is not the issue. The ThreadLocal is being properly cleared at the termination of each request during the execution of the finally clause in the SecurityContextPersistenceFilter. This is a class loader isolation issue. The issue is that a) the SecurityContextHolder class has a static reference to a 'strategy' object. b) When a request goes to war1 the SecurityContext class is loaded from war1, initialized and the strategy object is created out of the classes in war1. c) When a request next goes to war2, the SecurityContext class for war2 is loaded from the war2 (correctly) but it's static field STILL points to the strategy object created in (b), from war1! d) Because the strategy object was loaded from war1, when it's "createEmptyContext()" method is called, it creates a SecurityContextImpl instance using the class for that from war1. e) Finally, this will "fail" when you attempt to use this object within war2 because assigning it to a reference of type SecurityContext will throw a ClassCastException. It will throw the ClassCastException because the object implements the SecurityContext interface from war1, not war2. The core problem is in step "c" : Why is the static field for the SecurityContextHolder class in war2 pointing to the strategy object from war1? A static field should belong to a class. The SecurityContextHolder class in each war are, as we both agree, supposed to be separate classes. So they are supposed to have completely separate static fields. Thanks again for your attention to this. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
