It turns out that if an event handler invalidates the session, it has
to nullify only those ASOs that it (the handler) has used.
Here's the requested example. It fails unless we either:
(a) comment out the first line of onActionFromLogOut() because it
references _myASO; or
(b) un-comment the line that sets _myASO to null.
It seems this is an unintended consequence of TAP5-399?
<html xmlns:t="the usual xsd stuff">
<body>
<a t:type="actionlink" t:id="LogOut" href="#">Log Out</a>
</body>
</html>
package jumpstart.web.pages;
import org.apache.tapestry5.annotations.ApplicationState;
import org.apache.tapestry5.ioc.annotations.Inject;
import org.apache.tapestry5.services.RequestGlobals;
import org.apache.tapestry5.services.Session;
public class TestInvalidate {
@Inject
private RequestGlobals _requestGlobals;
@ApplicationState
private String _myASO;
void setupRender() {
_myASO = "Everything's fine";
}
void onActionFromLogOut() {
System.out.println("_myASO = " + _myASO + ".");
Session session =
_requestGlobals.getRequest().getSession(false);
if (session != null) {
// _myASO = null;
session.invalidate();
}
}
}
Cheers,
Geoff
On 11/12/2008, at 12:11 AM, Ville Virtanen wrote:
Hi,
we have exactly the same setup -> invalidate session + redirect to
login,
and have no such problems. (Four production systems that I have
played with
all seem to be fine.)
The documentation says:
Assigning a value to an ASO field will store that value. Assigning
null to
an ASO field will remove the ASO (reading the field subsequently
will force
a new ASO instance to be created).
so it is a bug if we can replicate. Can you provide simple page that
replicates this? (Two pages?)
- Ville
