How can it be the same thread? I was under the impression that the servlet responded to the client w/ a 301/302/303 status code. The HTTP client would then make a second request to a resource whose value is found in "Location" response header.
One non-session solution would be to manipulate the response header by adding query string params, in which case the second request would have to be a GET and the query string would have to be under 255 characters in order to make it past some HTTP proxy servers. One other option would be to simply drop the typical servlet redirect altogether. The JSF spec says an implementation has to redirect the user agent, but AFAIK, it does not specify how this is done. One solution that could get you past these problems is to simply render a page that would simulate a redirect w/ javascript for the DOM onload event. Obviously this isn't an option for people w/out javascript enabled, but the benefit is that you could use POST. This means no size limit and you could even maintain the viewstate in a faces request -> faces response fashion. I would prefer your session idea to this however, as it is more simple. Perhaps you could maniplate the "Location" response header in order to specify a globally unique session attribute key. This would avoid the very small chance of a concurrent modification exception when removing the message. Also, beware of storing UIMessage in the session, as it is not serializable. Probably just want to go w/ it's state of course. Dennis Byrne >-----Original Message----- >From: Travis Reeder [mailto:[EMAIL PROTECTED] >Sent: Monday, March 27, 2006 07:25 PM >To: 'MyFaces Development' >Subject: Re: Messages when redirecting > >It could be optional too, maybe a setting in web.xml like the other >extensions settings. > >The thread local won't work, because a redirect is not in the same thread >(well it could be, but that would be leaving things to luck). ;) > >Travis > >On 3/27/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: >> >> On 3/27/06, Travis Reeder <[EMAIL PROTECTED]> wrote: >> > Anyone opposed to doing something like this for messages after a >> redirect: >> > >> > 1. Save messages in session >> > 2. Use messages in session and remove from session >> > >> > Rather than just on the request? This way, they can be shown after a >> > redirect. At least in the tomahawk messages tag anyways. >> >> I don't think it's a good idea. The end-developer may not want a >> session created. Is it reasonable to assume that a thread-local >> variable could be used instead since the same thread will continue >> processing the request? I'm not really an expert on servlets or >> thread-local variables, so consider this more of a -0 than a -1. >> >> And if we do handle messages like this, I'd like to see us also handle >> saveState behavior like this as well. I suppose we might need a >> "preserveAcrossRedirect" attribute set on saveState to insure we >> support the existing behavior in case someone is counting on redirects >> to fail to saveState. >> >
