Ronald Klop wrote: > Op vrijdag, 3 juli 2009 17:48 schreef Mark Thomas <ma...@apache.org>:> >> Christopher Schultz wrote: >> > Ronald, >> > > On 7/3/2009 6:34 AM, Ronald Klop wrote: >> >> I'm running Tomcat 6.0.20 in a cluster on 3 nodes. If I restart one I >> >> get this exception: >> > > >> Caused by: java.io.NotSerializableException: >> >> org.apache.catalina.users.MemoryUser >> > > That's an easy one: MemoryUser does not implement Serializable. >> > >> <!-- Used by Manager webapp --> >> >> <Resource name="UserDatabase" auth="Container" >> >> type="org.apache.catalina.UserDatabase" >> >> description="User database that can be updated and saved" >> >> factory="org.apache.catalina.users.MemoryUserDatabaseFactory" >> >> pathname="conf/tomcat-users.xml" /> >> > > This is likely to be the problem: the manager app is trying to >> share its >> > users across the cluster. >> >> Unlikely. The manager app isn't marked as distributable. >> >> My money would be on an app using the same Realm and putting the >> authenticated >> Principal object in the session. >> >> Mark >> >> > > Hi, > > Thanks for your answers. The context has a security-constraint in > web.xml for some password-protected pages for metainfo/stats about the > running app. This takes a user defined in tomcat-users.xml. > > I looked a little into the Tomcat code. In > ./java/org/apache/catalina/connector/Request.java on line 1752 Tomcat > puts the 'javax.security.auth.subject' on the session. This is the > MemoryUser in my case I think. > > Is there a way to use the security-constraint in a clustered environment?
Looking into the history a little, the reason for this is a performance optimisation when using a SecurityManager. Possible workarounds: - disable the security manager - use a HttpSessionActivationListener and remove this attribute before the session gets passivated It looks like a Tomcat bug to me. If you add it to Bugzilla someone will take a look. Possible patches include: - make memory user serializable - use a session note rather than an attribute Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org