attribut bouton de commande JSF est transféré de manière incorrecte

Question

Je code suivant dans la page JSF, soutenu par bean géré JSF

<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>

Ce fragment de code est dédié à l'édition collection d'articles viennent. Chaque ligne de la table contient le bouton « modifier » qui présente les valeurs modifiées de la ligne sur le serveur. Il a l'élément lui-même comme un attribut. Soumettre est effectuée en appelant la méthode actionListener dans le support géré haricot.

Ce code fonctionne correctement sur Glassfish v 2.1

Mais quand le serveur a été mis à jour Glassfish v 2.1.1, l'attribut est arrêté pour être transmis correctement. Au lieu de passer élément modifié (lorsque l'on change les valeurs dans la ligne de la table, nous changeons réellement les champs de l'objet sous-jacent), l'élément source est soumis au serveur, à savoir l'élément qui a été précédemment donné à la page. Toutes les modifications apportées sur la page sont mis au rebut.

J'ai essayé de mettre à jour la version de jsf 1.2_02 à 1.2_14 (nous utilisons RI jsf), mais il n'a eu aucun effet.

Peut-être que quelqu'un est venu dans le même problème? Toute aide et suggestions seront appréciées.

Answer 1

navires Glassfish avec JSF fourni. navires Glassfish de v2.1.1 avec Mojarra 1.2_13 . Vous n'avez pas vraiment besoin d'avoir vos propres libs JSF dans le /WEB-INF/lib. Je ne sais pas comment ce problème est dû, mais pour commencer, vous devez vous assurer que vous n'avez pas collisions version JSF dans le classpath.

Cela dit, la voie JSF 1.2 préféré de faire passer des propriétés de haricots est à l'aide f:setPropertyActionListener.

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

Mise à jour : Je me rappelle quelque chose; ce problème suggère que vous avez encore une version JSF 1.2 plus ancienne que 1.2_05 autour du classpath. Traitement des attributs de composants a changé par cette version en faveur des améliorations de performance. En un mot, si vous avez un jsf-api.jar de plus que 1.2_05 dans votre classpath, alors qu'il ya un jsf-impl.jar de 1.2_05 ou plus récent dans votre classpath, vous ferez l'expérience exactement ce problème.

La solution est évidente: le nettoyage de votre classpath pour se débarrasser de la version JSF ancienne. Les chemins couverts par le classpath par défaut de l'application Web sont sous chaque /WEB-INF/lib, Appserver/lib (qui est en cas de Glassfish quelque part dans Appserver/domains/domainname/*) et le JRE/lib et JRE/lib/ext. Gardez à l'esprit que la javaee.jar GlassFish comprend des bibliothèques JSF aussi bien, si vous avez vraiment besoin de vous assurer que vous n'avez pas JAR (ou tout autre fichier JAR spécifique à serveur d'applications) dans votre /WEB-INF/lib ou ailleurs.

Answer 2

Vous pouvez ajouter JBoss EL et écrire:

#{poolBean.updatePool(item)}

Vous n'avez pas besoin toute Seam pour cela, fonctionne très bien avec JSF RI.

Answer 3

Probablement qu'il a à voir avec la façon dont JSF 1.2 implémente actionListener. Dans JSF 1.1 et jusqu'à ce que les mises en œuvre récentes de JSF 1.2 (RichFaces, Trinidad, etc.), l'ordre était setPropertyActionListener (ou attribut) -> actionListener -> action. Dans JSF 1.2 et maintenant mis en œuvre RichFaces et Trinidad (pas sûr Icefaces) l'ordre est actionListener -> setPropertyActionListener (ou attribut) -> action. Je sais qu'il est inquiétant et très ennuyeux ... Qui pensait? Qu'ont-ils à l'esprit? Quoi qu'il en soit, essayez d'utiliser une action au lieu d'un actionListener et voir si cela fonctionne.