Hi everyone,
I'm having a bizarre problem with Tapestry, and I'm hoping someone here
might be able to point me to a solution. Before I go into detail I'd
like to describe the problem generally, in the hopes that it might be a
known problem or someone may have encountered something similar.
The problem is that Tapestry 4.1.6 sometimes injects the wrong
application state object on my pages! As you can imagine, this plays
havoc with my application, with users seeing other users' details, or
even worse, changing other users' information! It's a support and
security nightmare.
I'm using Tapestry 4.1.6, and I'm using annotations instead of XML
files. My pages all descend from a base class:
public abstract SupplierDNAPage extends BasePage {
@InjectState
public abstract SupplierDnaSession getSupplierDnaSession();
@InjectStateFlag
public abstract boolean getSupplierDnaSessionExists();
...
}
hivemodule.xml contains the following:
<?xml version="1.0" encoding="UTF-8"?>
<module id="com.supplierdna" version="0.0.0">
<contribution configuration-id="tapestry.state.ApplicationObjects">
<state-object name="supplier-dna-session" scope="session">
<create-instance class="com.supplierdna.logic.SupplierDnaSession"/>
</state-object>
</contribution>
...
</module>
SupplierDNA is the name of the company I'm writing this for. As I
understand it, this is the correct way of using application state
objects. And most of the time, it works perfectly. When testing locally
I have no problems with wrong application state being injected, and our
demo system also doesn't have the problem.
The problems seem to start when the server is heavily loaded. Then,
sometimes, getSupplierDnaSession() will return an application state
object from a different session!!!
I have verified this by adding a pageBeginRender() listener method to
the base class, and a client address property to the session. The
listener method checks whether the client address stored on the session
it gets from Tapestry is the same as the client address from the current
request, and throws an exception if this is not the case. On our
production server, this happens dozens of times a day!
The method also directly retrieves the application state object from the
HttpSession and compares it to the one it got from Tapestry, and it
turns out that the application state object on the HttpSession is the
correct one, but somehow Tapestry is injecting a different one! This
seems to rule out the web container as being the culprit (which is
Glassfish 2 update 2, in this case).
Obviously this is a complex problem with a potentially huge number of
contributing factors, but first I'd just like to know whether this
sounds familiar to anyone? Is there a known problem with Tapestry which
could cause this? Has anyone ever experienced something similar? Many
thanks in advance for any help you can give me!
Kind regards,
Pepijn Schmitz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
