tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronald Klop <ronald-mailingl...@base.nl>
Subject Re: NotSerializableException MemoryUser?
Date Thu, 09 Jul 2009 12:46:27 GMT



Op donderdag, 9 juli 2009 14:22 schreef Mark Thomas <markt@apache.org>:
> 
> Ronald Klop wrote:
> > Op vrijdag, 3 juli 2009 17:48 schreef Mark Thomas <markt@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
> 
>  



Yep. I thought the same. The SecurityManager is needed for RMI as far as I know. So I can't
get rid of that one. The session clustering doesn't mean the session is passivated every time
I think, but I will take a look on that one. Maybe a SessionBindingListener which directly
removes the attribute. All ugly hacks in my opinion.

I wil file a bug report.

Thanks,

Ronald.




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message