On 11/11/2013 3:58 PM, Christopher Schultz wrote:
> Terrence,
>
> On 11/11/13, 4:31 PM, Terence M. Bandoian wrote:
> > On 11/11/2013 2:29 PM, Jose Irrazabal wrote:
> >> Thanks for the reply
> >>
> >> I generate the session in a servlet in doPost method that would
> >> be:
> >>
> >> protected void doPost ( HttpServletRequest request ,
> >> HttpServletResponse response) throws ServletException ,
> >> IOException {
> >>
> >> */ / create the session* HttpSession session = request.getSession
> >> ( ) ;
> >>
> >> */ / set attribute* session.setAttribute ( " idser " p_iduser )
> >> ; session.setAttribute ( "username" , p_username ) ;
> >>
> >> */ / redirect to page " menu.jsp "* response.sendRedirect ( "
> >> menu.jsp " ) ;
> >>
> >>
> >> } */ / end method*
> >>
> >> On page " menu.jsp " I get the attribute with :
> >>
> >> session = request.getSession ( false); String userid = (String )
> >> session.getAttribute ( " userid " ) ; String user = (String )
> >> session.getAttribute ( "user") ;
> >>
> >> It is possible that this code *HttpSession session =
> > request.getSession ( )* ;
> >> this bad and how I can correct it.
> >>
> >> It is possible that this code:* session = request.getSession
> >> (false )*, this bad and how I can correct it.
> >>
> >> They could give me an example of how to work with sessions
> >> (create and capture) in a Java application with JSP, please
> >>
>
>
> > Hi, Jose-
>
> > Is your request variable the implicit object provided by the JSP
> > container?  Do you maintain a reference to the request object
> > anywhere?
>
> > Do you maintain a reference to the session object anywhere?  Also,
> > there is an implicit session object provided by the JSP container
> > which is set before your code is executed in a JSP page so it
> > shouldn't have to be set again in menu.jsp.  However, if you do
> > call request.getSession and include a false argument, it would
> > probably be best to check for a null return value.
>
> > Are you sure your servlet is always executed before menu.jsp for a
> > given session?
>
> > One thing you might consider is implementing HttpSessionListener
> > and removing all of your application-specific attributes in the
> > sessionDestroyed method.  That might help make the situation more
> > clear.
>
> > You might also consider setting your session attributes in a
> > servlet filter rather than in a servlet.  That would eliminate the
> > need for a redirect.
>
> request -> servlet -> JSP using a forward is fairly typical. Redirects
> are slightly less common but there's no reason there should be any
> suspicion about a problem, there.
>
> In this case, the data is being stored in the session (and not the
> request) so doing a redirect (or forward) is not much different from a
> pass-through filter.
>
> It's pretty clear that the code above is for example/testing purposes,
> so I wouldn't treat this as a real-world scenario.
>
> -chris


Hi, Cris-

I think I provided a clear response with some useful suggestions to
consider.

-Terence


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to