tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Callender <geoff.callender.jumpst...@gmail.com>
Subject Re: [VOTE] Release 5.0.18 as FINAL 5.0 release
Date Thu, 11 Dec 2008 12:54:25 GMT
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">
	<a t:type="actionlink" t:id="LogOut" href="#">Log Out</a>

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 {

	private RequestGlobals _requestGlobals;

	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;


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message