Looks like this is a bug in 5.0.18 that has been fixed in 5.1.0.0. See
http://issues.apache.org/jira/browse/TAP5-413 for details.
-Dave
On Mon, Mar 9, 2009 at 6:11 PM, Dave Dombrosky <dom...@gmail.com> wrote:
> Sorry I may have jumped the gun. I thought I had this fixed, but I
> must have been testing on Jetty and not Tomcat. Still broken in
> Tomcat.
>
> -Dave
>
>
> On Mon, Mar 9, 2009 at 5:49 PM, Dave Dombrosky <dom...@gmail.com> wrote:
>> Peter, returning true "works", but it does not redirect the user to a
>> different page than they were on. Normally you want the user to be
>> sent to a different page if they are in a secure area of the site when
>> logging off.
>>
>> I was just able to fix my problem with a similar situation. I was
>> trying to return my home page as a Class, but Tapestry did not like
>> initializing the page after the session had been invalidated. To
>> solve this, I injected the page using @InjectPage, and then used that
>> value in the method return. The key here seems to be getting the page
>> initialized before the session is invalidated.
>>
>> Now for Harald's case, this might be difficult to implement. It looks
>> like he's got a dynamic start page that he wants a user to be returned
>> to. Somehow he's going to have to get an instance of the page and
>> return that, instead of returning a URL. I'm not quite sure how to do
>> that here, but maybe someone else can chime in.
>>
>> -Dave
>>
>>
>> On Mon, Mar 9, 2009 at 5:46 AM, Peter Stavrinides
>> <p.stavrini...@albourne.com> wrote:
>>> Sorry here is the rest of it:
>>>
>>> public Object onActionFromLinkLogoff() {
>>> User user = userDao.load(getVisit().getUserId());
>>> auditDao.audit(AuditType.LOGOFF, user);
>>>
>>> String startPage = getVisit().getStartPage();
>>> componentResources.discardPersistentFieldChanges();
>>>
>>> if (null != session)
>>> request.getSession(false).invalidate();
>>> return true;
>>> try {
>>> return new URL(startPage);
>>> } catch (MalformedURLException e) {
>>> return null;
>>> }
>>> }
>>>
>>>
>>> --
>>> If you are not an intended recipient of this e-mail, please notify the
>>> sender, delete it and do not read, act upon, print, disclose, copy, retain
>>> or redistribute it. Please visit http://www.albourne.com/email.html for
>>> important additional terms relating to this e-mail.
>>>
>>> ----- Original Message -----
>>> From: "Peter Stavrinides" <p.stavrini...@albourne.com>
>>> To: "Tapestry users" <users@tapestry.apache.org>
>>> Sent: Monday, 9 March, 2009 11:30:05 GMT +02:00 Athens, Beirut, Bucharest,
>>> Istanbul
>>> Subject: Re: [T5 5.0.18] java.lang.IllegalStateException: Cannot create a
>>> session after the response has been committed
>>>
>>>>I have a filer to trim off the long jsession IDs from url
>>> You can do so, but IMHO that should never be necessary, the session id is
>>> encoded into the URL only once, and then removed by the container (that is
>>> if you have cookies enabled in the browser). It provides a backwards
>>> compatibility mechanism and support for devices that can't support cookies.
>>> The only other reason that it might be encoded request after request is if
>>> you are creating a new session with each request (a configuration problem
>>> that can happen for instance when you have a problem with your front end -
>>> Apache mod_rewrite), which is not mapping your cookie correctly to your
>>> back end (Tomcat / Jetty etc).
>>>
>>> Returning true is interpreted as a terminator for the request by your
>>> container, false allows the request to continue naturally, so if you call
>>> something like session.invalidate(), immediatly after call return true; to
>>> terminate, invalidate acts like a finalize on the request, so anything that
>>> trys to do something with it will cause an IllegalStateException.
>>>
>>> The problem I was having the other day related to lazy loading, after an
>>> invalidate, I could not initialize a new page because a new session could
>>> not be instantiated at that point, simply setting the property before the
>>> invalidate fixed that, the second issue was the use of the Response
>>> Tapestry service rather than HttpServletResponse, where the later cannot be
>>> tracked by Tapestry so there is a timing issue (like a race condition),
>>> hence using the first was the solution.
>>>
>>> Cheers,
>>> Peter
>>>
>>>
>>> ----- Original Message -----
>>> From: "Dave Dombrosky" <dom...@gmail.com>
>>> To: "Tapestry users" <users@tapestry.apache.org>
>>> Sent: Monday, 9 March, 2009 05:46:16 GMT +02:00 Athens, Beirut, Bucharest,
>>> Istanbul
>>> Subject: Re: [T5 5.0.18] java.lang.IllegalStateException: Cannot create a
>>> session after the response has been committed
>>>
>>> I'm also getting an exception after a session.invalidate() from an
>>> ActionLink and can confirm that it works in Jetty but fails in Tomcat.
>>> It would be nice to know if there is a workaround. Here's the
>>> exception:
>>>
>>> java.lang.IllegalStateException: Cannot create a session after the
>>> response has been committed
>>> org.apache.catalina.connector.Request.doGetSession(Unknown Source)
>>> org.apache.catalina.connector.Request.getSession(Unknown Source)
>>> org.apache.catalina.connector.RequestFacade.getSession(Unknown
>>> Source)
>>> javax.servlet.http.HttpServletRequestWrapper.getSession(Unknown
>>> Source)
>>>
>>> org.apache.tapestry5.internal.services.RequestImpl.getSession(RequestImpl.java:99)
>>> $Request_11fda81101a.getSession($Request_11fda81101a.java)
>>> $Request_11fda810fec.getSession($Request_11fda810fec.java)
>>>
>>> org.apache.tapestry5.internal.services.SessionApplicationStatePersistenceStrategy.requestDidComplete(SessionApplicationStatePersistenceStrategy.java:126)
>>>
>>> org.apache.tapestry5.internal.services.EndOfRequestListenerHubImpl.fire(EndOfRequestListenerHubImpl.java:40)
>>> ...
>>>
>>>
>>> On Fri, Mar 6, 2009 at 6:47 AM, Angelo Chen <angelochen...@yahoo.com.hk>
>>> wrote:
>>>>
>>>> I have same error, the reason is, I have a filer to trim off the long
>>>> jsession IDs from url, solution was, I stopped using invalidate in the T5
>>>> side. however, according to Peter, this happens when you have a
>>>> sendRedirect
>>>> without a matching return true in a dispatcher, you can try that.
>>>>
>>>>
>>>> Harald Geritzer-2 wrote:
>>>>>
>>>>>
>>>>> hi all,
>>>>>
>>>>> the following code causes IllegalStateExceptions on tomcat 6 while using
>>>>> jetty it works without
>>>>> errors. any idea?
>>>>>
>>>>> public URL onActionFromLinkLogoff() {
>>>>> User user = userDao.load(getVisit().getUserId());
>>>>> auditDao.audit(AuditType.LOGOFF, user);
>>>>>
>>>>> String startPage = getVisit().getStartPage();
>>>>> Session session = request.getSession(false);
>>>>>
>>>>> componentResources.discardPersistentFieldChanges();
>>>>>
>>>>> if (null != session)
>>>>> session.invalidate();
>>>>> try {
>>>>> return new URL(startPage);
>>>>> } catch (MalformedURLException e) {
>>>>> return null;
>>>>> }
>>>>> }
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/-T5-5.0.18--java.lang.IllegalStateException%3A-Cannot-create-a-session-after-the-response-has-been-committed-tp22369307p22369465.html
>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
