Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Gary VanMatre <gvanmatre <at> comcast.net>
Subject: Re: Client-id : _id0 is duplicated in the faces tree.
Newsgroups: gmane.comp.apache.shale.user
Date: Thursday 1st March 2007 02:45:25 UTC (over 9 years ago)
>From: "Richard Eggert"  
>
> I'm running into a problem using "Xml views" using HTML templates.
Loading a 
> page initially works fine, but if I reload the page either by clicking on
a link 
> or hitting Refresh, I get the following error. 
> 
> 
> java.lang.IllegalStateException: Client-id : _id0 is duplicated in the
faces 
> tree. 
> at 
>
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspS

> tateManagerImpl.java:241) 
> at 
>
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspS

> tateManagerImpl.java:255) 
> (the above line is repeated several times) 
> at 
>
org.apache.myfaces.application.jsp.JspStateManagerImpl.savedSerializedView(JspSt

> ateManagerImpl.java:204) 
> at 
>
org.apache.shale.clay.faces.ClayViewHandler.renderView(ClayViewHandler.java:418)

> ... 
> 
> The error goes away if I load the page again, and then comes back if I
load the 
> page again after that. 
> 
> I created a very simple test page to reproduce the problem: 
> 
> bugTest.html 
> --------------- 
>
>
>   
>      Testing
>      
>      
>      
>      
>   
>   
>      foo
>   
>
>
>
> 
> 
> clay-views.xml (excerpt) 
> ---------------------------- 
> 
>
>   
>      
>   
>
> 
> (web.xml maps *.clay to the Faces servlet and the Shale application
filter) 
> 
> I don't know if this is a bug in MyFaces (I'm using version 1.1.1), a bug
in 
> Clay, or if I'm doing something wrong, but I've never seen this problem
before 
> with my other (non-Clay-based) pages. Any ideas? 
> 

 
Darn, I thought we had this one covered for all the releases but I must not
have tested again with myfaces 1.1. There is some history with this issue.


This has to do with how the view root generates component ids. For
components that you don't explicitly assign a component id, there is a
utility function on the view root to generate a unique Id. In the first
versions of Myfaces and the RI, the internal sequence that generates the
ids was always reset even after the view was restored.


This is a significant because of components marked transient. Transient
components do not save state in the view. The “verbatim” component is
actual an outputText with the transient property tunned on. When the view
is restored, we have to recreate transient components and these components
will need generated component id's since this is just text. In the early
version of clay, after the view was restored, we would generate, in
sequence, component ids for all components including components that were
restored because this counter was always reset. A clay html template
contains allot of transient components because the entire template is
defined using components (Thanks again to Manfred Klug who helped figure
this all out). Interesting enough, making all the view represented by
components is the same approach they took in JSF 1.2. 


The EG team determined that reseting the counter was a “bug”. The view
root should restore the internal counter. Starting with version 1.1.2,
myfaces changed the view roots to restore the counter. 


Clay Release 1.0.3
http://issues.apache.org/struts/browse/SHALE-195


The counter being reset made PPR or any changes to a restored component
tree problematic. So, in JSF 1.2 they changed how component id's are
generated. They are now generated by the the container for JSP tags
implementing JspidConsumer (JSP 2.1). The JspidConsumer will always return
the same id for a component.


Most recently, changes were made in this area to allow Clay to work with
JSF 1.2. 


Clay Release 1.0.4
http://issues.apache.org/struts/browse/SHALE-67


I thought that I had this covered for all releases but it sounds like it's
an issue. Trying to play with all versions is challenge. I'd like to move
the trunk to full JSF 1.2 support and leave the 1_0_X branch for JSF 1.1
flavors. There are features in JSF 1.2 that we can not support until we
commit to the new EL API.


Please create a JIRA issue on this one.


> 
> Rich Eggert 
> Member of Technical Staff 
> Proteus Technologies, LLC 
> http://www.proteus-technologies.com

> 
> 

Gary

> 
> 
>
 
CD: 12ms