[ https://issues.apache.org/struts/browse/SHALE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig McClanahan updated SHALE-418: ----------------------------------- Comment: was deleted > Exception "Client-id : _id0 is duplicated in the faces tree" occurs with > MyFaces 1.1.1 > -------------------------------------------------------------------------------------- > > Key: SHALE-418 > URL: https://issues.apache.org/struts/browse/SHALE-418 > Project: Shale > Issue Type: Bug > Components: Clay > Affects Versions: 1.0.4 > Reporter: Richard W. Eggert II > Assignee: Gary VanMatre > Fix For: 1.0.5 > > > From mailing list discussion with Gary VanMatre: > >From: "Richard Eggert" <[EMAIL PROTECTED]> > > > > 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 > > --------------- > ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN"> > ><html> > > <head> > > <title>Testing</title> > > <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" /> > > <meta http-equiv="pragma" content="no-cache"> > > <meta http-equiv="cache-control" content="no-cache"> > > <meta http-equiv="expires" content="0"> > > </head> > > <body> > > foo > > </bod y> > ></html> > > > > > > > > > > clay-views.xml (excerpt) > > ---------------------------- > > > ><component jsfid="/bugTest.clay" extends="clay"> > > <attributes> > > <set name="clayJsfid" value="/path/to/bugTest.html" /> > > </attributes> > ></component> > > > > (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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.