Skip to main content

Debugging "java.lang.IllegalStateException: Duplicate component id" error

I recently noticed an issue reported with below stack trace. Here the run time complaints about the presence of duplicate id in the jsf page. Interestingly, none of the components used in the page shares the same id. So what goes wrong here?

java.lang.IllegalStateException: Duplicate component id: 'pt1:USma:0:MAnt1:0:pt1:Perio1:0:ap1:r9:requestBtns:localeView:si1', first used in tag: 'com.sun.faces.taglib.jsf_core.SelectItemsTag'
+id: j_id__ctru0
  type: javax.faces.component.UIViewRoot@53eff13
   +id: doc1
    type: RichDocumentUIXFacesBeanImpl, id=doc1
     +id: pt1
      type:$ContextualFacesBeanWrapper@4bcc1b1, id=pt1
       +id: r1
        type: RichRegionUIXFacesBeanImpl, id=r1
         +id: p1
          type: RichPopupUIXFacesBeanImpl, id=p1
           +id: dia1

Let me share a couple of points which may help you to narrow down this issue.

1. If you use multiple instances of same task flow in a page, please make sure that you define separate binding for each task flow. This is really needed as each task flow instance needs to live in their own world.

Wrong Implementation:
<af:region value="#{bindings.myTaskflowdefinition1.regionModel}"
<af:region value="#{bindings.myTaskflowdefinition1.regionModel}"
Correct Implementation:
<af:region value="#{bindings.myTaskflowdefinition1.regionModel}"
<af:region value="#{bindings.myTaskflowdefinition2.regionModel}"
2. While building a task flow, please make sure that scope specified for manged bean is not visible from another instances of the same task flow. This means that backingBean, view and pageFlow may be the right 'scope' choices depending on your use case requirement. Please avoid request, session and application scopes unless you have specific reason for that.
Why? The issue is that, in some cases you may need to access the UI component from manged bean and apparently you may go for binding the component with bean. Here, if you chose a scope which is visible from another instances of the same task flow, that may cause unpredictable behavior later and may result in the above said error as well.

Please go through chapter 14.2.4 What You May Need to Know About Memory Scope for Task Flows from Oracle® Fusion Middleware Fusion Developer's Guide to learn more.


Excellent solution worked perfectly. I will bookmark ur blog for any future adf references. Thanks

Popular posts from this blog

How to set Bind Variable Values at runtime ?

In this post I'm sharing a couple of approaches for programmatically setting bind variables values at run time. This post is an attempt to explain 'When to use what ?'[ In case if you are familiar with 'Bind Variables' in ADF BC, please refer Section 5.10, Working with Bind Variables in Fusion Developer's Guide ]

1. Set the Bind Variable value using RowSet::setNamedWhereClauseParam(...)

You can use use the setNamedWhereClauseParam(...) method on the ViewObject interface (which extends oracle.jbo.RowSet) to set the value for bind variables. Please note this sets the value on default RowSet. In other words, this doesn't have any effect on the secondary RowSets that you/system generates.
ViewObject vo = am.findViewObject("EmployeesView1"); vo.setNamedWhereClauseParam("bindVarDeptId", new Number(10)); vo.executeQuery();
2. Set the Bind Variable value using ViewObject's VariableValueManager::setVariableValue(...)

VariableValueManager Ma…

Happy New Year 2018 !

We can't go back and change the beginning, but we always can start where we are and change the ending. Believe in yourself and you will be unstoppable!

Wishing you and your family a very happy new year 2018 !!!