7

I already asked this question in the WildFly forum but did not get any answers so far. So I´m trying here.

Since I upgraded from WildFly 8.1 to 8.2 I have problems with a commandButton inside a tabView connected to a bean.

Here is a simple JSF page:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://xmlns.jcp.org/jsf/html"
      xmlns:p="http://primefaces.org/ui">
    <h:head></h:head>
    <h:body>
        <h:form>
            <p:tabView binding="#{testBean.tabView}">
                <p:tab title="Tab">
                    <p:commandButton value="Inside" action="#{testBean.testInside}"/>
                </p:tab>
            </p:tabView>
            <p:commandButton value="Outside" action="#{testBean.testOutside}"/>
        </h:form>
    </h:body>
</html>

and the bean:

@Named
@SessionScoped
public class TestBean implements Serializable {
    private TabView tabView = new TabView();

    public TabView getTabView() {
        return tabView;
    }

    public void setTabView(TabView tabView) {
        this.tabView = tabView;
    }

    public void testInside() {
        System.out.println("inside");
    }

    public void testOutside() {
        System.out.println("outside");
    }
}

Clicking the "Inside" button triggers testInside() two times. The "Outside" button (outside of the tabView) behaves normally and triggers it´s method only once. Removing the tabView binding eliminates the problem. I´m using PrimeFaces 4.0.

Thanks for any ideas

Jan

jpstrube
  • 785
  • 1
  • 11
  • 27
  • 1
    Why is the binding (`binding="#{testBean.tabView}"`) needed at all? – Tiny Feb 02 '15 at 08:38
  • The binding is needed in the real application because the tabs are generated dynamically. – jpstrube Feb 02 '15 at 08:57
  • Can you try this minimal application with a newer PF version and check if it still happens? – Kukeltje Feb 02 '15 at 11:33
  • @BalusC you said "Components are request scoped, yet you're binding it to a session scoped bean", does that mean that we should always use binding with request scoped beans.? – Tarik Feb 02 '15 at 13:07
  • I think that i found some answers here in SO, that may also help the OP (attached links in BalusC answer are also very useful): http://stackoverflow.com/questions/18667927/how-to-use-component-binding-in-jsf-right-request-scoped-component-in-session – Tarik Feb 02 '15 at 13:12
  • @BalusC in some of your answers you said that Faces messages are request scoped and now components, is this because they are stored in the viewState ? i have tried to learn how they are request scoped from the code source but didn't succeed – Tarik Feb 02 '15 at 13:28
  • @BalusC So what caused the components or Faces messages to be request scoped ? – Tarik Feb 02 '15 at 13:33
  • @BalusC I understand the reason that it must be request scoped, but i just want to understand how they are request scoped in the code source? as even in the documentation i can't find that kind of information – Tarik Feb 02 '15 at 13:41
  • Ah yes, i am reading its spec now,Thank you @BalusC for your attention – Tarik Feb 02 '15 at 13:57

2 Answers2

7

It's a Mojarra 'issue', introduced by a performance optimization fix in 2.2.7.

this is a Mojarra "issue", I've discovered it when working on RF-13920, it was introduced by JAVASERVERFACES-3193. The components that use binding are not recreated during a request to the server but their children are. With the original children still in place inserting the new children causes the "duplicate id" error.

So it looks like your button is added twice, but since you do not have an explicit id assigned, you do not get the duplicate id error... Might be interesting to give that a try (adding an explicit id)

The JSF specification states that binding should only be used in Request scope, so I don't think it should be treated as a bug if this fails in Conversation scope.

The last remark is the interesting one. As is posted in the next post on the jboss site:

But now I think I have a satisfying solution for this issue and I can confirm, that with request-scoped backing beans for the component binding the exception and duplicate id problem does not occur anymore, even with Mojarra 2.2.8 from Wildfly-8.2.0.Final!

This is even true if the rest of the logic for the page remains in a (say) conversation scoped bean. You just need to have a request-scoped bean for the binding attribute, which then can be referenced in EL and other beans.

Check also this post

Community
  • 1
  • 1
Kukeltje
  • 12,223
  • 4
  • 24
  • 47
  • You are right, Assigning an id results in the duplicate id error. I will try to get along with Request scope or abandon the binding as BalusC suggested. – jpstrube Feb 02 '15 at 13:20
  • using mojarra 2.2.6 fixed my problem – ameen Oct 12 '17 at 14:05
  • yes unfortunately , I couldn't afford to refactor the code, downgrading seems working some how, though i am facing troubles with binding backbean of ViewScope – ameen Oct 16 '17 at 18:08
  • Bad choice... Bite the Apple and refactor... Always the netter choice. Especially since now you run into different issues @ameen – Kukeltje Oct 16 '17 at 19:14
  • you are right - but it is a lot and the task is time limited and already violated – ameen Oct 16 '17 at 20:26
-3

You can try doing in other way. Use remoteCommand out of the tab with the same action of the commandButton.
Then use the JavaScript function created by the remoteCommand in the onclick event of the commandButton.
Here is the example using your code.
It's functional.

<h:form>
    <p:remoteCommand id="myfun" name="myfun" action="#{testBean.testInside}" />
    <p:tabView binding="#{testBean.tabView}">
        <p:tab title="Tab">
            <p:commandButton value="Inside" onclick="myfun();"/>
        </p:tab>
    </p:tabView>
</h:form>
Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
malandres
  • 11
  • 3
  • 1
    Sure, but if you have 6 tabs, with 6 different buttons you need 6 remote commands. And using a commandButton in this case is also 'wrong', you should use a commandButton with `type="button"`... This solution is introducing more complexity then needed by doing it 'right' – Kukeltje Nov 29 '16 at 23:18