[ADFEMG-53] Enable User Customizations across Sessions using MDS can break ADF Application Created: 03/Sep/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Closed
Project: adfemg
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ulrich Gerkmann-Bartels Assignee: duncanmills
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive sample.mds.break.ui.zip    
Tags: mds



  • JDeveloper/ADF version : -
  • WebLogic Server version : n.a.
  • impact level : HIGH
  • why : break complete user interface interaction


Enable User Customizations across Sessions using MDS.

See blog post for detailed description and screenshots.

Steps to reproduce

  • Create a application with af:forEach and af:accordion for dynamic UI
  • Enable User Customizations across Sessions using MDS
  • (Optional) Deactivate all persistent options for showDetailItem
  • Run ADF App
  • Try to open the accordion several times

Occured result/behaviour

  • after some clicks the ui freeze and must be refreshed

Expected result/behaviour

  • Enable User Customizations across Sessions using MDS should not have negative impact on the application.


Further information

Comment by duncanmills [ 04/Sep/12 ]

My suspicion here would be specifically aimed at the use of af:forEach within the accordion - checking this out.

Comment by duncanmills [ 04/Sep/12 ]

Right I've done some digging in this.
We started to support the persistence of items within iterators and forEach in 11.1.2+ So that probably has a bearing on this.
Running in Chrome I can observe the following:
1) If I run without 'Enable User Customizations' when it works OK
2) If I run with 'Enable User Customizations' but only for the duration of the session it works although the response on the disclose seems a little sluggish
3) If I run with 'Enable User Customizations' Across Sessions then the first disclose does not quite fail - there is a slight UI change but the detail is not shown. Subsequent disclose attempts generate a JavaScript error "Unexpected panelAccordion showDetailItem disclosure state for queueing client events" If you then refresh the page then it starts to function.

Comment by duncanmills [ 04/Sep/12 ]

OK I think I've got to the bottom of this and it's simple to fix. The root of the issue here is a difference in behaviour between JSP and Facelets as a page technology.
The JSP engine has some hacks in it to prevent duplicate IDs in the case of a forEach loop. Facelets does not so you have to be careful.
The solution in your example is to either:
1) Remove the ID attribute from your showDetailItems and let JSF generate them.
2) Amend the ID attribute to something like: <af:showDetailItem id="sdi3_#


" ... to ensure a unique id

This will ensure that every instance of the showDetail has a unique ID.

Give that a go...

Comment by Ulrich Gerkmann-Bartels [ 04/Sep/12 ]

Great - i try (2) and i can confirm it works

Comment by duncanmills [ 04/Sep/12 ]

This is down to the behaviour of unique ID generation (or not) within the scope of forEach loops.
See: https://blogs.oracle.com/groundside/entry/foreach_and_facelets_a_bugfarm

Comment by Jan Vervecken [ 04/Sep/12 ]

Thank you for the insights Duncan.

As you write in your blog post [1]

  • (st1) "... JSF under JSP implements some hacks ... to transparently fix this problem for you ..."
  • (st2) "... when running with Facelets ... JSF does not mess around in the background for you ..."
  • (q1) Are both (st1) and (st2) intended behaviour?

It seems strange that for a given af:forEach the run-time behaviour can be so different.
Or is this covered by the af:forEach tag documentation [2] saying
"Note: this tag is not supported in Facelets, because c:forEach is fully functional in Facelets."

Jan Vervecken

Comment by duncanmills [ 04/Sep/12 ]

There is no need to use af:forEach in facelets because c:forEach works correctly. Note that af:forEach was only created in the first place because of shortcomings in the JSTL version.
However, af:forEach does still function and I think that it actually just uses c:forEach internally anyway.
The actual problem here is discussed in the JavaServer Faces issues repository (it's a JSF issue not an ADF issue): http://java.net/jira/browse/JAVASERVERFACES-1527, as you see it's the same for both af: and c:forEach

Generated at Sat Nov 28 08:25:58 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.