>From: "Richard Eggert" <[EMAIL PROTECTED]> > > Thanks for the explanation! I've reported it as SHALE-418. > > Is there a workaround, or do I just have to wait until I'm able to upgrade to > MyFaces 1.1.4 (which won't be until late next week at the earliest)? >
Unfortunately, I can't think of a workaround other than using clay 1.0.3. http://shale.apache.org/docs/release-notes-1.0.3.html http://shale.apache.org/docs/release-notes-1.0.4.html I'll try to get to this one this weekend... > > Rich Eggert > Member of Technical Staff > Proteus Technologies, LLC > http://www.proteus-technologies.com > > Gary > > -----Original Message----- > From: Gary VanMatre [mailto:[EMAIL PROTECTED] > Sent: Wed 2/28/2007 9:45 PM > To: user@shale.apache.org > Subject: Re: Client-id : _id0 is duplicated in the faces tree. > > >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 > > --------------- > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > >
