JSF Befehlsschaltfläche Attribut wird falsch übertragen

Question

Ich habe folgenden Code in JSF-Seite, unterstützt von JSF Managed Bean

<h:dataTable value="#{poolBean.pools}" var="item">
    <h:column>
        <f:facet name="header">
                <h:outputLabel value="Id"/>  
        </f:facet>
        <h:outputText value="#{item.id}"/>
    </h:column>
    <h:column>
        <f:facet name="header">
            <h:outputLabel value="Start Range"/>
        </f:facet>
        <h:inputText value="#{item.startRange}" required="true"/>               
    </h:column>
    <h:column>
        <f:facet name="header">
            <h:outputText value="End Range"/>
        </f:facet>
        <h:inputText value="#{item.endRange}" required="true"/>                            
    </h:column>
    <h:column>
        <f:facet name="header">
            <h:outputText value="Pool type"/>
        </f:facet>            
        <h:selectOneMenu value="#{item.poolType}" required="true">
            <f:selectItems value="#{poolBean.poolTypesMenu}"/>
        </h:selectOneMenu>
    </h:column>
    <h:column>
        <f:facet name="header"/>
        <h:commandButton id="ModifyPool" actionListener="#{poolBean.updatePool}" image="img/update.gif" title="Modify Pool">
            <f:attribute name="pool" value="#{item}"/>
        </h:commandButton>
    </h:column>
</h:dataTable>

Dieses Codefragment ist spezialisiert auf die Bearbeitung kommen Sammlung von Gegenständen. Jede Zeile der Tabelle enthält Schaltfläche „Bearbeiten“, dass vorträgt Werte der Zeile mit dem Server geändert. Es hat das Element selbst als Attribut. Abschicken wird durch Aufruf Action Methode in der Träger Managed Bean durchgeführt wird.

Dieser Code läuft korrekt auf Glassfish v 2.1

Aber wenn der Server Glassfish v 2.1.1 aktualisiert wurde, blieb das Attribut korrekt übergeben werden. Statt bearbeiten Stück vorbei (wenn man die Werte in Tabellenzeile ändern, werden wir tatsächlich die Aufgabe zugrunde, Felder ändern), wird das Quellelement an dem Server übermittelt, das heißt die Position, die zuvor auf der Seite gegeben wurde. Alle Änderungen, die auf der Seite gemacht wurden, werden verworfen.

habe ich versucht, zu aktualisieren JSF-Version von 1.2_02 zu 1.2_14 (wir JSF RI verwenden), aber es hatte keine Wirkung.

Vielleicht jemand kam über das gleiche Problem? Jede Hilfe und Vorschläge werden geschätzt.

Answer 1

Glassfish Schiffe mit gebündelten JSF. Glassfish v2.1.1 Schiffe mit Mojarra 1.2_13 . Sie brauchen eigentlich keine eigene JSF Libs im /WEB-INF/lib haben. Ich bin nicht sicher, wie dieses besondere Problem verursacht wird, sondern zu starten, müssen Sie sicherstellen, dass Sie nicht JSF-Version Kollisionen im Classpath haben.

sagte, dass der bevorzugte JSF 1.2 Weg bean Eigenschaften vorbei ist f:setPropertyActionListener verwendet wird.

<h:commandButton id="ModifyPool" actionListener="#{poolBean.updatePool}" image="img/update.gif" title="Modify Pool">
    <f:setPropertyActionListener target="#{poolBean.pool}" value="#{item}"/>
</h:commandButton>

Aktualisieren : Ich habe etwas erinnern; Dieses Problem lässt vermuten, dass Sie immer noch eine JSF 1.2-Version älter als 1.2_05 um in dem Classpath haben. Handhabung von Komponentenattribute gemäß dieser Version für Leistungsverbesserungen geändert. Auf den Punkt gebracht haben, wenn Sie einen jsf-api.jar von älter als 1.2_05 in Ihrem Classpath, während es in Ihrem Classpath ein jsf-impl.jar von 1.2_05 oder höher ist, werden Sie genau dieses Problem auftritt.

Die Lösung liegt auf der Hand: Bereinigungs Classpath der älteren JSF-Version loszuwerden. durch den Standard-Classpath abgedeckt Pfade des Webapp sind unter jedem /WEB-INF/lib, Appserver/lib (die im Fall von Glasfischen irgendwo in Appserver/domains/domainname/* ist) und die JRE/lib und JRE/lib/ext. Beachten Sie, dass die Glassfish javaee.jar JSF-Bibliotheken als auch beinhaltet, so dass Sie wirklich brauchen, um sicherzustellen, dass Sie nicht, dass die JAR (oder andere appserver spezifische JAR-Datei) in Ihrem /WEB-INF/lib oder woanders.

Answer 2

Sie können hinzufügen JBoss EL und schreiben:

#{poolBean.updatePool(item)}

Sie brauchen nicht die ganze Naht für das, funktioniert mit JSF RI.

Answer 3

Wahrscheinlich hat es mit der Art und Weise JSF 1.2 implements Action zu tun. In JSF 1.1 und bis vor wenigen Implementierungen von JSF 1.2 (Richfaces, Trinidad usw.) die Reihenfolge setPropertyActionListener (oder Attribute) war -> Action -> Aktion. In JSF 1.2 und jetzt in Richfaces und Trinidad (nicht sicher IceFaces) ist der Auftrag Action implementiert -> setPropertyActionListener (oder Attribute) -> Aktion. Ich weiß, es ist beunruhigend und sehr ärgerlich ... Wer dachte, dass es? Was haben sie vor? Wie auch immer, versucht, eine Aktion statt einer Action und sehen, ob es funktioniert.