Robert Nicholson wrote:
> Where can I read about how things are stored in the session?
>
> In particular is it a deep copy of the object? ie. recursively copies all
> reference objects too?
>
> ie. if I have an object reference that's stored in the session (the object I
> assume) and I change some state.. If I ask for it out of the session again
> what state will it show?
>
Think of a session as a Hashtable (which is how most servlet containers actually
implement the attribute storage), and you will understand how it works. There
is no copying at all going on -- all you are doing is storing an additional
reference to the same object.
>
> I'd also like feedback on the following.
>
> The site i'm at has the following user hierarchy
>
> User
>
> Authenticated User
>
> Admin User
>
> ....
>
> Basically you can have three types of users and unfortunately they used
> subclassing. I say unfortunately because these things are stored in the
> session and it's common to see code like this
>
> AuthenticatedUser u = (AuthenticatedUser)unauthenticatedUser
>
> and
>
> AdminUser a = (AdminUser)u
>
> and every now and then you get casting exceptions because the code doesn't
> deal with the permuations correctly.
>
> Is it not better to simply use state on a regular User account to indicate
> authentication or not and administritive rights and just use User types
> without subclassing?
>
> Is putting subtypes of types in the session discouraged? What I mean is not
> being consistent about the type of the object for the key and having no
> other indicator of the object other than instanceof?
>
Class cast exceptions in this case are an indication of an application logic
bug.
There is a way to ask the object whether it is an instance of a particular class
or interface so that you can proactively avoid problems:
Object u = session.getAttribute("user");
if (u instanceof AdminUser) {
((AdminUser) u).xxx(...);
} else if (u instanceof AuthenticatedUser) {
((AuthenticatedUser) u).yyy(...);
} else if (u instanceof User) {
((User) u).zzz(...);
} else {
... something bad was stored under the "user" key ...
}
>
> ....
>
> I would feel much more comfortable using bit flags/state etc on a regular
> User type and just putting those in the sessions rather than assuming that
> under the key UESR in the session could be a User or AuthenticatedUser or
> AdminUser
>
That would be the other way to do it. But that means that the "combined" user
object has to have all the properties of each possible type of user, even if
they are not relevant for the particular type of this object.
>
> .....
>
> Anyone care to chime in here?
>
> ---
> Robert Nicholson
> Email: [EMAIL PROTECTED]
> AOL : rydmerlin
>
Craig McClanahan
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
