Heck, you might even be able to get the second suggestion to work using a filter. Of course, if you do use the second method, you'll have to be sure to *remove* the messages from the FacesContext or the session after rendering the page, or they're just going to stay there. The advantage of them being stored in the request in the first place is that the request object is by nature transitory, so if you take away that advantage you're going to have to implement it yourself in whatever solution you choose.
-Matt
On 5/24/05, Victor Tatai <[EMAIL PROTECTED]> wrote:
Wouldn't you happen to know a way around this restriction? I would
prefer to use redirect as it allows the use of bookmarks to pages.
Thanks,
Victor
On 5/23/05, Matt Blum < [EMAIL PROTECTED]> wrote:
> The messages are stored in the request object, and doing a redirect will
> create a new request object, so yes, this is expected behavior. There is a
> way to get the filters to fire even if you do a forward, as detailed in this
> message I wrote on a thread from a couple of weeks ago:
>
> http://makeashorterlink.com/?Y5D61202B
>
> HTH.
> -Matt
>
>
> On 5/23/05, Victor Tatai <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > We have a myfaces (1.0.9) application which uses global messages
> > extensively in order to notify the user about errors, successful
> > actions, etc. However when we add the <redirect/> tag to the
> > navigation cases the messages simply stop appearing. Is this a bug or
> > it is an expected behavior? Is there any way around this? We need the
> > redirect in order to enable proper activation of the servlet filters.
> >
> > Thanks,
> >
> > Victor
> >
> > --
> > "Make things as simple as possible, but no simpler"
> > -- Albert Einstein
> >
>
>
--
--
"Make things as simple as possible, but no simpler"
-- Albert Einstein
--
--
"Make things as simple as possible, but no simpler"
-- Albert Einstein
