Ok, I'm confused... Are you asking why you get a new session before the user
authenticates? Without actually looking at the configuration, I assume that is
the intended behavior. If you are coming back in through the JSF framework in
the redirect, I would expect it to create a session if a valid one does not
exist. As to why the User class is being created, that makes sense if you have
it associated with that particular incoming event. As I said, I'm not that
familiar yet with JSF life cycle, but I would assume it is because the incoming
event requires that managed bean. If JSF is using a lazy create for instances,
not instantiating until needed, that may explain the single object instance.
That's how Struts works with Actions, and since C. McClanahan is responsible
for JSF now, that would be consistent with how he operated before.
The question I have is where the logging line for the create is happening? And
whether what you are seeing is the old bean or the old values set into the new
bean. You might want to put some logging in your setters to see what's
happening there. I'd say to turn up the level of logging in the RI JSF stuff,
but I've already perused it a bit and the log statements are pretty sparse
unless there's an error. There's Sun for you :)
That doesn't help you figure out why the values on it are the old ones though.
If you download the RI source( I have the latest 04 build, but I assume the
older versions are out there), you will see a directory called
javaserverfaces_sources. The two directories you want to look in are jsf-api
(interfaces) and jsf-ri (implementations). Not sure what you are using for an
IDE. In Eclipse all you would need to do is rmb on the jar in question and
specify the path to the source. I used to use IDEA quite a bit, and there is a
dialog there to specify the source path as well. JDeveloper or Netbeans you
are on your own :)
Anyway once you get your source hooked up up all you need to do is set the
breakpoints at a bunch of spots, fire up a debug session on your local
server(assuming you are OK with doing that?) and run through your flow. Just
look in the memory as you go to see what is happening with the objects. I'd
probably focus on the Context implementations to begin with and see what
happens from there. It may take a few runs through to narrow down where its
going on.
I know it looks like a lot of work. You might just get what you need if you
google and check out whether there's an article on what's going on under the
covers in the JSF cycles. But once you get it and you know what's going on
it's going to help you figure out the next issue. And there will be one.
---- Rich Schramm <richard.schramm@xxxxxxxxxxxxxxxxxx> wrote:
> I took James suggestion and added session listeners to the app. It
> appears (see below) that a new session is being created automatically as
> soon as I redirect to the logout or index page. Using redirect, I am
> getting the behavior I expect (the user is prompted to login before
> getting to the home page) but the user is still using the session that
> was created for them after the session was destroyed but before they are
> prompted to authenticate (with the user object accompanying it). After
> authenticating, they have the correct user principle, but the session
> from the last user (with the last user's user object). See below:
>
> 08-27@14:55:35 DEBUG (SessionMgmt:26) - SessionMgmt Class
> instantiated.
> 08-27@14:55:35 DEBUG (SessionMgmt:50) - Logout listener called.
> Destroying Session...
> 08-27@14:55:35 DEBUG (SessionEventListener:25) - Session Destroyed.
> 08-27@14:55:35 DEBUG (SessionMgmt:55) - Session should now be
> destroyed. About to redirect via response.sendRedirect.
> 08-27@14:55:35 DEBUG (SessionMgmt:57) - Redirecting...
> 08-27@14:55:35 DEBUG (SessionMgmt:59) - Redirection sent.
> 08-27@14:55:35 DEBUG (SessionEventListener:20) - Session Created.
> 08-27@14:55:35 DEBUG (User:31) - User Class instantiated.
>
> So - why (and how) would it create a new user session prior to
> authentication, and subsequently why would it create a new managed bean
> user object during that process when it is not called by anything? And
> why would it not instantiate the OTHER 3 managed beans during that
> process?
>
> I am using the 1.2 RI. If you know of a way to hook into the RI to see
> where and why the session and managed beans are instantiated, I would
> appreciate you passing that on.
>
> Thanks,
>
> Rich
|