Skip to main content

Intermittent, but reproducible (!), corruption of the session map

3 replies [Last post]
Joined: 2010-01-26

Hi, I've got something strange going on here.

My Mojarra 2.0.3 app stores a reference to a user entity in the session map
on successful login,

<br />
@ManagedProperty(value = "#{sessionScope}")<br />
    private Map sessionMap;</p>
<p>...getters & setters ...</p>
<p>public User getCurrentUser() {<br />
        return (User) getSessionMap().get("currentUser");<br />
<p>    public void setCurrentUser(User currentUser) {<br />
        SQLog.log();<br />
        getSessionMap().remove("currentUser");<br />
        if (currentUser != null) {<br />
            getSessionMap().put("currentUser", currentUser);<br />
        }<br />
    }<br />

What I'm seeing is that after a code change and redeploy I will intermittently
get a version of the application that is trashing my stored user reference. I've
got an excerpt from the server log below. This shows that the app is logging a
call to setCurrentUser (the numbers are source line numbers). The loginAction()
method has successfully authenticated the user and I can see a session id
ending in 19751d and the user with username healeyb has been stored in the session map with the key "currentUser".

I then try to perform an operation via the GUI, I've not logged out (we'd have seen
a call to setCurrentUser() setting the user reference to null), I then try to get the
session id, and it's the same as before, ending in 19751d. I then try and get the
user reference but it's null (exception caused by attempt to access username from
null pointer).

SEVERE: SportQuest:
SEVERE: SportQuest:
SEVERE: Session Id: b75728894b1af5e07c396e19751d User: healeyb
SEVERE: SportQuest:
SEVERE: Session Id: b75728894b1af5e07c396e19751d
SEVERE: java.lang.NullPointerException

So the question is what's happened to the reference to the User instance I've
put in the session map with the key "currentUser"? I've not removed the map
entry or I'd see a call to setCurrentUser().

The interesting thing is that when I have a version of the app deployed that has
this problem it will do it every time. If I then force a rebuild and redeploy by, for
instance adding a space in the code of some arbitrary source code and then
removing the space, doing a Run Project in NetBeans I then get a version that
always works.

If anyone has any suggestions for further debugging tactics I'll give it a try, but
I'm at the limit of my knowledge in terms of how to progress this. I can't see any
reason why garbage collection would be an issue here as the entry in the session
map is a reference to the User instance?


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2010-01-26

This problem turns out to be caused by using
@ManagedProperty(value = "#{sessionScope}") to access the session map
(via getters and setters).

As described in the original post it doesn't work in every build. When I access
the hashCode value of the session map itself I can see that it is 0 when I'm
encountering the problem, which should clearly never happen.

Reverting back to the long hand notation below to access the session map
and straight away everything works fine every time:


The only other information that I can think of that would be of interest is that I'm
putting a value into the session map from a request scoped managed bean and
accessing it again from a view scoped bean, but this clearly shouldn't matter at

So something not right with the resource injection. I do have PrimeFaces 2.0.2
and RichFaces 4A2 libs included in my project, using Mojarra 2.0.3 release build.


Ed Burns

>>>>> On Mon, 19 Jul 2010 02:32:33 PDT, said:

BH> This problem turns out to be caused by using
BH> @ManagedProperty(value = "#{sessionScope}") to access the session map
BH> (via getters and setters).

Do you have the annotation on the instance variable *and* have a
corresponding getter and setter? This is an unfortunate inconsistency
between JSF managed beans and JavaEE managed beans. We aim to fix this
in JSF 2.1.

I certainly hope this works in Mojarra 2.0.3 because I consider it a
best practice to inject session scope in this way.


| edburns... | office: +1 407 458 0017
| homepage: |

To unsubscribe, e-mail:
For additional commands, e-mail:

Joined: 2010-01-26

Hi Ed, you'll have recognised the code then, copied directly from your extremely
helpful book JSF 2, The Complete Reference, a book I use every day.

My code did have getters and setters, NetBeans generated, for all the instance
variables annotated with @ManagedProperty, for example in the case of the
sessionMap variable I had getSessionMap and setSessionMap. The getter and
setter [i]methods[/i] are not annotated in line with your own AbstractBacking class.

I'm quite sure there's a little bug in there somewhere, because this problem has
completely gone away since I ditched the use of the @ManagedProperty
annotation, and I am using 2.0.3. Unless of course there's something strange
with my environment, but I suspect not.