Mailing-List: contact issues-help@shale.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shale.apache.org
Message-ID: <14874758.1173577431195.JavaMail.jira@brutus>
Date: Sat, 10 Mar 2007 17:43:51 -0800 (PST)
From: "Gary VanMatre (JIRA)" <jira@apache.org>
To: issues@shale.apache.org
Subject: [jira] Resolved: (SHALE-418) Exception "Client-id : _id0 is
 duplicated in the faces tree" occurs with MyFaces 1.1.1
In-Reply-To: <18346143.1172726897016.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/struts/browse/SHALE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary VanMatre resolved SHALE-418.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 1.1.0-SNAPSHOT
                   1.0.5-SNAPSHOT
         Assignee: Gary VanMatre

The first analysis of this problem lead in the direction of trying to determine the version of myfaces.  Depending on the version, clay would behave differently.  

However, after some thought I determined that it would be just as easy to always generate a unique id regardless of if it was used.  This approach should work for both behaviors of the view root.

I've also added some logic to attempt to cleanup unused components under a Clay managed subtree.  

Fix is in the 20070311 nightly.  We appreciate the help.

> 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
>         Assigned To: Gary VanMatre
>             Fix For: 1.0.5-SNAPSHOT, 1.1.0-SNAPSHOT
>
>
> From mailing list discussion with Gary VanMatre:
> >From: "Richard Eggert" <reggert@proteus-technologies.com>
> >
> > 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.