Wildfly-8.2.0.Final: IllegalStateException (duplicate component id)

[ahaumer]

This week I tested a rather large application on Wildfly-8.2.0.Final for the first time (we currently use Wildfly-8.1.0.Final in production).

The EAR deploys fine, I can log in and work with most parts of the application, but for some use cases I get an IllegalStateException because of duplicate component id's

The use case is like this:

1. The application shows a list of entities in a rich:dataTable
2. The user selects a single entity by clicking on the contents of a cell in a row
3. The application shows a detailled view of the entity and presents a "back" button
4. The user clicks on the "back" button

With Wildfly-8.1.0.Final, the application goes to step (1) again (this is the expected result)

With Wildfly-8.2.0.Final, the application crashes with an IllegalStateException ("component-id already found in view") like this:

Caused by: java.lang.IllegalStateException: Komponenten-ID j_idt220:tab:j_idt250 wurde bereits in der Ansicht gefunden.

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:987) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:971) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:971) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:971) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:971) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:971) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.saveView(FaceletPartialStateManagementStrategy.java:461) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.application.StateManagerImpl.saveView(StateManagerImpl.java:89) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.application.view.WriteBehindStateWriter.getState(WriteBehindStateWriter.java:328) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.application.view.WriteBehindStateWriter.flushToWriter(WriteBehindStateWriter.java:221) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:473) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]

        at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]

        at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]

        at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]

        at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.8-jbossorg-1.jar:]

        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]

        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]

        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]

        at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:56) [omnifaces-1.7.jar:1.7]

In the component-tree dump I see the whole set of columns of the data table duplicated!

I see this problem consistently in all similar use cases in our application (about 40 use cases)

I found two workarounds for this problem so far, which might give you a clue of what is going on here:

1) Start a new conversation when the user clicks on the "back" button.

The "back" button in the entity detail view is a h:button like this:

        <h:button id="listButton" value="Back" outcome="/admin/entityList.xhtml">

          <f:param name="cid" value="#{javax.enterprise.context.conversation.id}"/>

        </h:button>

If I remove the f:param line with the conversation ID, I get a new conversation, but no exception.

2) Replace mojarra-2.2.8 from Wildfly-8.2.0.Final with mojarra-2.2.6 from Wildfly-8.1.0.Final

Both workarounds I'd rather not deploy in production... :-)

I'm using RichFaces-4.5.1.Final

Now I'm wondering: ist this a bug in Wildfly-8.2.0.Final (Mojarra-2.2.8), a bug in RichFaces or a bug in my application?

I'm asking here, because the application runs unchanged without problems with Wildfly-8.1.0.Final, but shows the exception with Wildfly-8.2.0.Final and nothing else changed

(In fact in my tests I'm deploying the same EAR)

I'm sorry I can't present a simple demo application for this problem. I'm in an early stage of problem solving and still gathering information.

The application in question is rather big and involves our own components and framework code which of course might add to the situation.

Still I think we have a valid JEE application (prove: it works with Wildfly-8.1.0.Final ;-). So something must have changed with Wildfly-8.2.0.Final / Mojarra-2.2.8 which actually triggers the problem.

So what might that be?

Any idea anyone?

[ctomc]

It is mojarra bug

try using 2.2.9. that should have this problems fixed.

try with https://repository.jboss.org/nexus/service/local/repositories/releases/content/com/sun/faces/jsf-impl/2.2.9-jbossorg-1/j…

[ahaumer]

Hi Tomaz!

Thanks for the quick reply!

I replaced jsf-impl with 2.2.9-jbossorg-1 as you suggested.

Wildfly is now starting with

2015-01-07 16:08:23,829 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-13) Mojarra 2.2.9-jbossorg-1 20141218-1439 für Kontext '/emcs' wird initialisiert.

so it seems it picked up the new version.

Alas, the application still crashes with the same error:

Caused by: java.lang.IllegalStateException: Komponenten-ID j_idt220:tab:j_idt253 wurde bereits in der Ansicht gefunden.

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:987) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:971) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:971) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:971) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:971) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.util.Util.checkIdUniqueness(Util.java:971) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.saveView(FaceletPartialStateManagementStrategy.java:460) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.application.StateManagerImpl.saveView(StateManagerImpl.java:89) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.application.view.WriteBehindStateWriter.getState(WriteBehindStateWriter.java:326) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.application.view.WriteBehindStateWriter.flushToWriter(WriteBehindStateWriter.java:221) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:473) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]

        at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]

        at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]

        at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]

        at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.9-jbossorg-1.jar:2.2.9-jbossorg-1]

        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]

        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]

        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]

        at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:56) [omnifaces-1.7.jar:1.7]

        ... 43 more

In the component tree dump I still see all the UIColumn components (+ child components) of the data table duplicated.

Did I miss something?

[ahaumer]

Today I did more testing and found the following interesting details:

1) I found even more use cases in our application where this problem occurs!

All use cases have the following in common:

• A page with a rich:dataTable is used to show a list of entities
• On the first view of this page in a new conversation, everything works as expected.
• If this page is then viewed a second time in the same conversation, an IllegalStateException due to ducplicate component id is thrown
• If the page is viewed again, but in a new conversation, everything works

2) on the rich:dataTable we use the "binding" attribute to bind the component to a property of the backing bean.

If I remove this "binding" attribute (and replace the related business logic with some dummy code) the exception does not occur anymore!

Does this ring a bell with anyone?

BTW: I did all testing today with Wildfly-8.2.0.Final, patched with Mojarra 2.2.9-jbossorg-1

[nickarls]

I think I saw something similar with the new ICEfaces 4 line on WF 8.2, I think I actually downgraded mojarra to 8.1 level (2.2.6?)

[ahaumer]

Today I created a small application which has the minimum functionality to demonstrate the problem, using only a minimal set of standard JSF and RichFaces components!

The application can be built with Maven and can be deployed as WAR. No database is needed. Please see the attached file which contains the whole source code.

The application consists of two pages and a backing bean.

The first page shows a list of items, using a rich:dataTable

Each row in the table has a link to the second page (the "view" page), which shows nothing but two "back" buttons.

The backing bean is conversation scoped.

If you call the first page without conversation, a new conversation is started.

If you go to the "view" page and then click on the "Back (CID=n)" button which propagates the conversation, an llegalStateException is thrown.

If you click the "Back (new conversation)" button, a new conversation is started and no exception is thrown.

Things to notice:

1) If you remove the h:form around the rich:dataTable, no exception will be thrown, but every time you show the page inside the same conversation, new columns will get added to the table!

2) If you remove the "binding=" attribute from the rich:dataTable, the application works

3) If you replace Mojarra (jsf-impl) from Wildfly-8.2.0.Final with Mojarra from Wildfly-8.1.0.Final, the application works.

4) If you deploy the WAR on Wildfly-8.1.0.Final, the application works.

I hope with this application someone with more knowledge about Wildfly, Mojarra and RichFaces than me can easily reproduce and eventually fix the problem.

I think with this demo application it's now pretty clear that this is a bug in the infrastructure and not in the application, but I don't know who should be assigned with this.

Should I file a bug report somewhere? Wildfly? Mojarra? RichFaces?

[ctomc]

Andreas Haumer wrote:

Should I file a bug report somewhere? Wildfly? Mojarra? RichFaces?

I am afraid that this is mojarra bug fjuma maybe has more info

[fjuma]

This looks like a RichFaces and/or Mojarra issue (there was actually a very similar issue a little while back: https://issues.jboss.org/browse/RF-12717) . Please create a RichFaces bug report to start out with: https://issues.jboss.org/browse/RF Thanks!

[ahaumer]

Done. See https://issues.jboss.org/browse/RF-13956

HTH

[michpetrov]

Hi,

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.

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.

[ahaumer]

Sorry for the late response, but I had a hard time refactoring our application to solve this issue. It had impact on about 70 backing beans, most of them conversation scoped (for a reason!).

I had to find a manageable solution which does not spoil the business logic in the beans and does not make maintaining the code more complex than it is already.

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.

This was an interesting issue and I would expect more people to fall into this trap as on the internet and even in books one finds examples which use non-request-scoped backing beans for component binding (e.g. "Core Java Server Faces", 3rd edition, Prentice Hall).

The change in Mojarra 2.2.8 and thus in Wildfly-8.2.0.Final might surprise some. Hopefully they'll find this thread when looking for a solution... ;-)

[gustavolacerdas]

Hi could you post some example code that you used to solve the problem?