users@javaserverfaces.java.net

RE: RE: RE: Re: Correct implementation of Phase Listener for session data.

From: Todd Patrick <Todd.Patrick_at_dtn.com>
Date: Thu, 2 Nov 2006 15:38:48 -0600

Don't get me started...

I am on a project and the other developers can't see the light. The
largest obstacle is that they don't have code complete in .xhtml files
within Eclipse.

Trust me, I'd like to have used Facelets, but on this project... I am
not.

Thanks,

--Todd

-----Original Message-----
From: Jason Lee [mailto:lee_at_iecokc.com]
Sent: Thursday, November 02, 2006 3:31 PM
To: users_at_javaserverfaces.dev.java.net
Subject: RE: RE: Re: Correct implementation of Phase Listener for
session data.

If you are using Facelets, the 1.2 RI can run under Tomcat 5. And if
you're not using Facelets, you should be. :)

-----
Jason Lee, SCJP
Programmer/Analyst
http://www.iec-okc.com
 

> -----Original Message-----
> From: Todd Patrick [mailto:Todd.Patrick_at_dtn.com]
> Sent: Thursday, November 02, 2006 2:42 PM
> To: users_at_javaserverfaces.dev.java.net
> Subject: RE: Re: Correct implementation of Phase Listener for session
> data.
>
> Unfortunately I am running Tomcat 5.0.28 on our DEV, QA and PRODUCTION

> environment, so I am using JSF 1.1
>
> (JSF 1.2 can only run in Glassfish or SJSAS 9.0 correct?)
>
> I am using server side state saving.
>
> Thanks,
>
> --Todd
>
> -----Original Message-----
> From: Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM]
> Sent: Thursday, November 02, 2006 2:20 PM
> To: users_at_javaserverfaces.dev.java.net
> Subject: Re: Correct implementation of Phase Listener for session
> data.
>
> Ryan Lubke wrote:
> > Todd Patrick wrote:
> >> "This seems fine, however, what do you plan to do if the
> session is
> >> no longer valid?"
> >>
> >> Good Point!
> >>
> >> I honestly don't know. Do you have a suggestion on how
> that should be
>
> >> handled?
> >>
> > Well, in 1.2, if you're using server side state saving and
> the session
>
> > becomes invalid a ViewExpiredException is thrown. You
> could leverage
> > the servlet error-page mechanism to catch that exception
> and redirect
> > the user to the login page (assuming you have a login page).
> NOTE - doing something like the above would eliminate the need for a
> custom PL.
> >
> > Maybe some others (like Mike or Jason) could share what they do in
> > such a case.
> >> I'll Google as well.
> >>
> >> Thanks,
> >>
> >> --Todd
> >>
> >>
> >> -----Original Message-----
> >> From: Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM] Sent:
> Thursday,
> >> November 02, 2006 2:02 PM
> >> To: users_at_javaserverfaces.dev.java.net
> >> Subject: Re: Correct implementation of Phase Listener for session
> data.
> >>
> >> Todd Patrick wrote:
> >>
> >>> Expanding on a thread labeled "Does an object that contains user
> >>> session data need to be a managed bean?"
> >>>
> >>> I am creating a class extending the Phase Listener.
> >>>
> >>> I want to check if my session object is valid for each
> page, thus I
> >>> thought that a Phase Listener would be the proper
> approach, since it
>
> >>> would be ran for each page.
> >>>
> >>> The phases RESTORE_VIEW and RENDER_RESPONSE are ran in
> the page Life
>
> >>> Cycle no matter, if I understand the docs correctly.
> >>>
> >>> Thus, is it proper to check my session object in the RESTORE_VIEW
> >>> phase or is there a better way?
> >>>
> >> This seems fine, however, what do you plan to do if the
> session is no
>
> >> longer valid?
> >>
> >>> Such as a Servlet with a /* URL Pattern, that would run for each
> >>> page as well.
> >>>
> >>> Thoughts on best practice is appreciated.
> >>>
> >>> Thanks,
> >>>
> >>> --Todd
> >>>
> >>> -----------------------------------------
> >>> NOTICE: This email message is for the sole use of the intended
> >>> recipient(s) and may contain confidential and privileged
> >>> information. Any unauthorized use, disclosure or distribution is
> >>> prohibited. If you
> >>>
> >>
> >>
> >>> are not the intended recipient, please contact the sender
> by reply
> >>> email and destroy all copies of the original message.
> >>>
> >>>
> >>>
> --------------------------------------------------------------------
> >>> - To unsubscribe, e-mail:
> >>> users-unsubscribe_at_javaserverfaces.dev.java.net
> >>> For additional commands, e-mail:
> >>> users-help_at_javaserverfaces.dev.java.net
> >>>
> >>>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> users-unsubscribe_at_javaserverfaces.dev.java.net
> >> For additional commands, e-mail:
> >> users-help_at_javaserverfaces.dev.java.net
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> users-unsubscribe_at_javaserverfaces.dev.java.net
> >> For additional commands, e-mail:
> >> users-help_at_javaserverfaces.dev.java.net
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail:
> users-help_at_javaserverfaces.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail:
> users-help_at_javaserverfaces.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: users-help_at_javaserverfaces.dev.java.net