Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: rogerk
Reporter: mst_70
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.

Facelets: Duplicate lclient Ids for components 'stamped' by c:ForEach

Created: 28/Jan/10 11:06 AM   Updated: 22/Oct/13 09:32 PM   Resolved: 29/Jul/10 09:38 AM
Component/s: facelets
Affects Version/s: 2.0.1
Fix Version/s: 2.1_gf31_m4

Time Tracking:
Not Specified

File Attachments: 1. Text File changebundle.txt (8 kB) 28/Jul/10 08:36 AM - rogerk
2. Text File foreach.diff (5 kB) 28/Jan/10 11:08 AM - mst_70


Operating System: All
Platform: All

Issue Links:

Issuezilla Id: 1,527
Status Whiteboard:

size_medium importance_large

Participants: Ed Burns, josefreire, kurtz_mr, Manfred Riem, mst_70, rogerk and Ryan Lubke

 Description  « Hide

If you repeat a component with c:forEach in Facelets, the current implementation
does not ensure that component's client Id is unique when Id is supplied as a
literal. Consider the following example:

<c:forEach var="person" items="${people.people}">
<h:inputText id="item1" value=#{}/>

This will produce duplicate client Ids with Facelets, but not with JSP.
If the id attribute is not specified, the unique Ids are generated.
While I understand that specifying literal Ids on the stamped components appears
to be a corner case (the client Ids will be impossible to predict anyways), we
have a real use case where component's Id attribute is used for integration with
an external content customization solution.

josefreire added a comment - 09/May/12 10:51 AM

There's a trivial workaround for this issue.

If the user wraps the <ui:include> with <f:subView>, there will be no id clash:

<c:forEach items="#{controller.list}" var="itemToInclude">
<ui:include src="#{itemToInclude}" />

The user clearly doesn't require the ids, so a f:subView is a reasonable and easy solution.

Could you please reopen this issue?

josefreire added a comment - 26/Apr/12 11:26 AM

This "fix" is a major regression and is a showstopper to our upgrade from JSF 1.2.

Issue is a clear example on how the effort to make this improvement broke the framework.

This issue should be reopened and a different approach should be considered.

<ui:include> should have some kind of flag to signal the framework to rewrite it's id's, and this should not be the default behaviour.

Manfred Riem added a comment - 23/Mar/12 05:05 PM

Closing resolved issue out

kurtz_mr added a comment - 10/Feb/12 04:41 PM

Is this fix really going in the right direction? I have

<c:forEach items="#{widgetController.widgets}" var="widget">
<ui:include src="#{widget.path}">
<ui:param name="widget" value="#{widget}"/>

Where I ensure myself ids in included facelets are unique. Too bad framework outsmarts me and replaces my ids with random garbage so I'm unable to do partial updates now.

josefreire added a comment - 29/Jul/10 09:38 AM

Hi everyone,

First a clarification: I confused this bug report with another one that is
present in Facelets 1.1
(, and it's still
present in JSF 2.0. I'll open a new issue to address it, and I've got a proposed
patch to upload.

Anyway, reading carefully this bug description I don't understand why this was
considered a bug in the first place.

The example code to illustrate the bug clearly forces the h:inputText to have
the same ID, resulting in many h:inputText with the same id in the component
tree, so in my opinion, this is clearly a programming error and the reference
implementation shouldn't be patched to handle this kind of situations.

I think that the real bug here is why it doesn't give a duplicate ID with JSP.

Just my 2 cents...

rogerk added a comment - 29/Jul/10 06:54 AM

checked in.

Ed Burns added a comment - 29/Jul/10 06:48 AM

Roger, because you are committing a patch supplied by Stevan, you can
give the r=rogerk yourself. For what it's worth, I have reviewed it as
well and give it r=edburns.


josefreire added a comment - 28/Jul/10 11:02 AM

Hi Roger,

Sure, I'll give my best shot. I think the approach I took in Facelets 1.1 is
still valid for JSF 2.0.

My first patches seem very similar to your patch. However I've found that with
this approach it broke state saving in some situations (ex: richfaces tree
stopped working correctly with server state saving).

rogerk added a comment - 28/Jul/10 10:40 AM

Hello Jose,

Your patch is really specific to Facelets (pre JSF 2.0 Facelets)..
Things have changed a bit for JSF 2.0 . Can you rework your patch
for JSF 2.0 Facelets? This issue is addressing JSF 2.0.

rogerk added a comment - 28/Jul/10 09:43 AM

Hey thanks Jose,

I'll take a look at your patch as well.
Stay tuned....


josefreire added a comment - 28/Jul/10 09:10 AM

Just a heads up.

This issue was identified on the facelets project, and my latest proposed patch
is very simple with very good results.

Please check, or the
latest proposed patch


rogerk added a comment - 28/Jul/10 08:36 AM

Created an attachment (id=1215)

rogerk added a comment - 27/Jul/10 08:54 PM


Ed Burns added a comment - 28/Jun/10 11:52 AM

Target for GlassFish 3.1 M4

rogerk added a comment - 28/Jun/10 10:34 AM

target 2.1_gf31_m4

rogerk added a comment - 25/Jun/10 11:58 AM


rogerk added a comment - 24/Jun/10 08:29 AM


Ed Burns added a comment - 11/Jun/10 02:09 PM

rogerk not roger

Ed Burns added a comment - 11/Jun/10 02:01 PM


Ed Burns added a comment - 03/Jun/10 01:12 PM

keywords separated by spaces

Ed Burns added a comment - 01/Jun/10 08:42 AM

ADF keywords

Ryan Lubke added a comment - 02/Feb/10 12:31 PM

Update target milestone.

mst_70 added a comment - 28/Jan/10 11:08 AM

Created an attachment (id=1084)
Patch for auto-generating Ids after the first stamped component