page forward doesn't display p:messages when using new p:autoUpdate component

[asesovici]

After updating to PrimeFaces 6.2, I've been replacing the obsolete autoUpdate attribute of p:messages with the new p:autoUpdate child component.

In one case it is not working as before. I have a login.xhtml page in which if the username is not filled in it will do a page forward to itself:

Code: Select all

if (username == null || username.trim().equals("")) {
	FacesMessage message = Utils.getMessageFromResourceFile("error.login.userName.required");
	FacesContext.getCurrentInstance().addMessage("loginForm", message);
	return "/login";
}

Within the same page, there is a p:messages that displays the error when autoUpdate is set as an attribute:

Code: Select all

<p:messages id="loginMessages" for="loginForm" autoUpdate="true" showDetail="false" closable="true" showIcon="false"/>

But it doesn't display it anymore when replacing the attribute with the p:autoUpdate component:

Code: Select all

<p:messages id="loginMessages" for="loginForm" showDetail="false" closable="true" showIcon="false">
	<p:autoUpdate/>
</p:messages>

Any idea what am I doing wrong?

[kukeltje]

Store the message in flashScope?

[asesovici]

Store the message in flashScope?

I am not doing a redirect so flashScope would not be necessary, right? I am trying to avoid using flashScope (had some problems in the past with it).

What I don't understand is what changed because it works when using the autoUpdate attribute but doesn't when using the p:autoUpdate component.

[kukeltje]

Ok, yes I missed that... Might be that not using the autoUpdate attribute prevents messages that are present when just rendering the page are not displayed.Try comparing the source of the 6.1 and 6.2 p:messages and see if something in this direction has changed... Making one small with a pre-render event and in it setting a message would in the 6.1 case work and not in the 6.2 case...

[matthew_dunlap]

My group is running into a similar issue to this when switching over to p:autoUpdate on one of our fragments. Did you find a resolution to this issue asesovoci?

[asesovici]

@matthew_dunlap no resolution so far, no. Ended up using the deprecated autoUpdate attribute of p:messages until there is no way out...

[kukeltje]

If either of you create a mcve http://stackoverflow.com/help/mcve I'm happy to investigate.

[kukeltje]

I experimented a little. My assumptions:

A page called index.xhtml with wwo messages components, a form and commandbutton with ajax and an action

Code: Select all

<h:body> 
           <p:messages id="loginMessages" autoUpdate="true" for="loginForm" showDetail="false" closable="true" showIcon="false"/>
           <p:messages id="loginMessages2" for="loginForm" showDetail="false" closable="true" showIcon="true">
		<p:autoUpdate/>
	    </p:messages>
            <h:form id="loginForm">
                <p:commandButton value="forward to self"  action="#{dfView.login}" />
            </h:form>
        </h:body>

And to easlily experiment in the bean I used

Code: Select all

public String login() {

		String returnVal = "/index";
		FacesMessage message = new FacesMessage("Returning " + returnVal);
		FacesContext.getCurrentInstance().addMessage("loginForm", message);
 		
 		//Flash flash = FacesContext.getCurrentInstance().getExternalContext().getFlash();
		//flash.setKeepMessages(true);
		return returnVal;
	}

When returned "/index" or "index" only the first one with the autoUpdate="true" attribute works
When I returned "" both work
When I returned null both work

When returned "/index?faces-redirect=true" or "index?faces-redirect=true" neither work unless I added the flash.setKeepMessages(true). Then both work.

I then added an additional p:messages without any autoUpdate and also added an explicit update for this new p:messages to the commandButton. The behaviour then is identical to the p:messages with the autoUpdate in that the test where "index" is returned work show the message.

I would personally return null or "" when I needed to stay at the same page anyway which is a good solution. It never the less is a difference that I for now cannot investigate further...