Hi,
FIRST
For non-specific Tomcat questions, it exists :
[EMAIL PROTECTED]
There's also an other one wich is JSP oriented.
SECOND
All best practice i know says that you must minimize the ammount of data
stored in the session. So, the traditional approach of this problem is to
only store the user-id (simple type) in the session. All over session
informations (a class containing all required informations) are stored in
the servlet context.
Praticaly, on the request you get the user id from the user session. Next
you use this Id to get the "user information obect" from the servlet
context.
This is certainly deceiving, but this is the way ...
Maybe someone knows better practice ?
Regards,
C�dric
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 01, 2002 6:13 PM
Subject: OT: howto avoid overuse of session object?
> This is sort of off-topic, but I don't know of a better forum targeting
Java
> web/servlet programming. If anyone does know of one, could you let me
know?
>
> I'm basically wondering if others have found effective ways to avoid the
> tempting but bad practice of loading up the session with all sorts of
> attributes. I often find myself needing some Bean or other object for
maybe 2
> or 3 requests, and, rack my brains as I may for an elegant way of passing
the
> object along without putting it in the session, I usually end up with
nothing
> more than a headache and 1 more attribute in my session. :( I'm
developing
> with an MVC approach, with Struts for more recently developed apps and a
> similar custom framework for our older apps, but I just can't seem to see
a
> way to get around this problem. I would love it if there were an object
like
> a thisRequestAndTheNextOne object, where attributes would stick around for
the
> current request and subsequent request, and then the controller could get
> objects from the previous request and determine if it should put them in
the
> new thisRequestAndTheNextOne object for the current request. I don't know
if
> that makes sense to anyone else, but, nevertheless, does anyone have any
ideas
> to do what I'm trying to do?
>
> Does anyone else feel my pain? ;)
>
> Thanks,
> -Jeff
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
