The list of <p:selectOneMenu> position is strange, when submit with "@form" update.

[hir0ku]

Issue Overview

when use "selectOneMenu" of PrimeFaces component, list position is strange.

Current Behaviour

• list position is header of page, when "commandButton" perfomed with "@form" update.

Expected Behaviour

• list position expect under component, when "commandButton" perfomed with "@form" update.

How to reproduce

<p:panelGrid id="panelGrid">
    <p:outputLabel for="@next" value="select one"/>
    <p:selectOneMenu value="#{indexView.selectOne}">
        <f:selectItems value="#{indexView.itemCandidates}" var="i" itemLabel="#{i}" itemValue="#{i}"/>
    </p:selectOneMenu>

    <p:commandButton value="submit"
                     process="panelGrid"
                     update="@form"
                     actionListener="#{indexView.submit}"/>

</p:panelGrid>

entire code is here. https://github.com/hir0ku/adminfaces-operation-verification/blob/master/src/main/webapp/index.xhtml

Additional Information

• AdminFaces version: 1.0.0
  • also try 1.0.2, same problem.
• PrimeFaces version: 7.0
• JSF implementation: Wildfly 16.0.0.Final Mojarra 2.3.9.SP01

[hir0ku]

I remove "org.omnifaces.resourcehandler.CombinedResourceHandler" from faces-config.xml. This problem dosen't occur.

Can "org.omnifaces.resourcehandler.CombinedResourceHandler" and admin-template not be together?

[rmpestano]

Hi @hir0ku, showcase and starter projects are using it so it should work together.

Can you reproduce here? https://adminfaces-adminfaces.apps.ca-central-1.starter.openshift-online.com/pages/sample/sample-form.xhtml? it uses selectCheckBoxMenu but would be easy to replace with selectOne/ManyMenu. If I find some time I can try that.

Also make sure to have clean browser caches

[hir0ku]

@rmpestano Thank you for your comments and giving hints and separating your time. I tried the showcase application in my enviroment, but this problem dosen't occur... 😢 I will continue to try to find the cause...

[rmpestano]

I think I made it work in your project, just upgrade OmniFaces to v3.2:

<dependency>
            <groupId>com.github.adminfaces</groupId>
            <artifactId>admin-template</artifactId>
            <version>${adminfaces.version}</version>
        </dependency>
        <dependency>
            <groupId>org.omnifaces</groupId>
            <artifactId>omnifaces</artifactId>
            <version>3.2</version>
        </dependency>

Can you try that?

[hir0ku]

It's work! Thank you very much!

Is it correct way to adding another version by myself in pom.xml? I think, admin-template should depends on 3.2 version of omnifaces.

[rmpestano]

Hi,

I think, admin-template should depends on 3.2 version of omnifaces.

The problem is that OmniFaces 3.2 is not compatible with JavaEE 6 (JSF 2.1, CDI 1.0 etc...) so we may break some apps if do the upgrade.

I think in admin-template 2.x we could make OmniFaces 3.x default as JavaEE6 is is 10 years old already.

[rmpestano]

Also it required Java 8:

OmniFaces 3.0 will explicitly prevent deployment when Java 1.8, JSF 2.3 or CDI 1.1 are absent in the environment.

[hir0ku]

I understand the circumstances surrounding this library. This issue will be closing. Thank you very much.

[rmpestano]

I've made some tests and your issue is also fixed with OmniFaces 2.7.1 so I'll upgrade admin-template to this version ~as it doesn't conflict with JavaEE 6~ (well it does but as JavaEE 6 is the less used version according to surveys we'll keep the upgrade) nor older versions of Java.

It will be available in admin-template 1.1.0.

Thank you very much for the feedback!