Major Description
It is possible to cause a duplicate id exception doing the following steps:
- Render one page (let's call mypage.xhtml) with a component that has a binding to a request scope managed bean
- Click the button
mypage.xhtml
....
<x:component binding="#
/>
<f:facet name="header">
/.... some components here with non generated id ..../
</f:facet name="header">
</x:component>
<h:commandButton action="#
">
....
bean
public String someMethod()
{
return "mypage";
}
That example should work without problem. The problem is raised by an optimization done in myfaces:
UIInstructionHandler
if (mctx.isRefreshingTransientBuild())
{
c = ComponentSupport.findChildByTagId(parent, id);
/....../
If we are not refreshing the current view, it does not have sense to try to find a component that will not be found, right?
The spec is clear about the effect of the previous example:
JSF 2.0 section 7.4.2 : "...A rule match always causes a new view to be created, losing the state of the old view. This includes clearing out the view map....."
but if you have component bindings on the page, all components inside the component with the binding will preserve the state. There is one simple solution from the user point of view (and this is what everyone usually does in this case):
public String someMethod()
{
return null;
}
no rule match means no navigation, the view state is preserved and finally no duplicate id exception.
If we disable the optimization code, the code will work, but there is still one problem with the spec.