Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Closed Closed
Resolution: Cannot Reproduce
Priority: Major Major
Assignee: Ed Burns
Reporter: Mathias Werlitz
Votes: 15
Watchers: 8

If you were logged in you would be able to see more operations.

Submitted value of UIInput gets lost inside composite components

Created: 15/Mar/11 06:17 AM   Updated: 02/Jul/12 09:36 AM   Resolved: 27/Jun/12 04:38 PM
Component/s: facelets, state saving, validation
Affects Version/s: 2.0.3, 2.0.4, 2.1.0
Fix Version/s: 2.1.11, 2.2.0-m05

Time Tracking:
Not Specified

File Attachments: 1. Text File 20120202-1543-i_mojarra_1991_reproducer.patch (11 kB) 02/Feb/12 08:44 PM - Ed Burns
2. Zip Archive (6 kB) 15/Mar/11 06:17 AM - Mathias Werlitz


JDK 1.6, Tomcat 6

Issue Links:

Status Whiteboard:

size_large importance_medium

Tags: composite
Participants: Adrian Gygax, anadollu, conpem, Ed Burns, joserodolfo.freitas, Manfred Riem, Mathias Werlitz, rogerk and tlind

 Description  « Hide

When a UIInput component are nested inside composite components, its submittedValue gets lost and is not rendered on validation errors.

This simple example fails:
<f:validateLength minimum="20"/>

The issue is present if the composite component inserts its childs with <cc:insertChildren />. When using facets with <cc:renderFacet /> it works correctly.

This issue seems to have a strong relation to JAVASERVERFACES-1825 because the conditions and possible workarounds are very similar.
Both bugs are really blockers. Composite components become useless this way.

Mathias Werlitz added a comment - 15/Mar/11 06:37 AM

The example shows a simple h:inputText and a h:inputText nested inside a very simple composite component.
If you enter a short text into both fields and submit the form, the submitted value of the simple h:inputText is redisplayed and the submitted value of the h:inputText nested inside the composite component is NOT on validation errors.

tlind added a comment - 24/Mar/11 11:01 AM

This seems to be a duplicate of JAVASERVERFACES-1784. I am also experiencing this problem and it basically makes composite components that contain input fields a no-go.

Mathias Werlitz added a comment - 05/May/11 05:00 AM

Well it seems that JAVASERVERFACES-2040 is the root cause of this problem.
My proposed patch will also fix this issue.

rogerk added a comment - 06/May/11 01:42 PM

Ok I am able to duplicate this problem.

joserodolfo.freitas added a comment - 01/Jun/11 11:21 AM

I workaround this problem putting <cc:insertChildren /> inside a h:panelGroup

<h:panelGroup >        

Adrian Gygax added a comment - 25/Aug/11 09:40 AM

<ui:fragment> worked for me as well as a workaround with the benefit that it doesn't render any addiontal HTML:


conpem added a comment - 27/Sep/11 08:12 AM

Hi Mathias!
I need help on this issue urgently. you write there is a patch that solves this problem. we are running with 2.0.4_b for now and no plans on upgrading jsf.
I created an issue: which regards the same bug about cc:insertChildren and using the wrap h:panelGroup
please if you have time look through it!


Ed Burns added a comment - 11/Jan/12 07:52 PM

Because a workaround exists, we can downgrade this from blocker status.

anadollu added a comment - 19/Jan/12 07:49 AM - edited

Hi Ed,

Please don't downgrade this issue from blocker, Becouse workaround is not valid for all versions. 2.1.5 version don't work with this workaround. In my opinion, this issue should be considered as blocker.


Mathias Werlitz added a comment - 29/Jan/12 09:35 PM

The problem is that state saving of composite components is broken in Mojarra. I don't understand why this fundamental problem doesn't get fixed. It's already open for 10 months. I explained in detail what goes wrong and supplied a patch for the root cause of the problem JAVASERVERFACES-2040. This will also fix this issue.

Ed Burns added a comment - 02/Feb/12 08:59 PM

Here's the cause of the problem:

On render, we have a new instance for the UIInput inside the CC, whereas
we have the same instance for the UIInput outside the CC.

The workaround, which enables me to de-prioritize this from Blocker to Major, is to use value binding or component binding in the case of the inner component.

I'll continue to work on this as high priority, though.

Ed Burns added a comment - 02/Feb/12 09:05 PM

Believe it or not, the reason this one is a problem is because of our hack approach for the implementation to cc:insertChildren and cc:insertFacet.

It's a duplicate of JAVASERVERFACES-1985.

Ed Burns added a comment - 02/Feb/12 10:02 PM

I don't understand why InsertChildrenHandler.apply() is called once on
the initial render and twice on the postback. That seems incorrect.

Ed Burns added a comment - 02/Feb/12 10:02 PM

I don't understand why InsertChildrenHandler.apply() is called once on
the initial render and twice on the postback. That seems incorrect.

Mathias Werlitz added a comment - 03/Feb/12 08:54 AM

Hi Ed,

yes, JAVASERVERFACES-1985 is the problem here and is part of the problem of JAVASERVERFACES-2040. Please see my analysis of JAVASERVERFACES-2040. InsertChildrenHandler.apply() is added and called twice because the component tree is rebuild a second time before rendering.

My patch for JAVASERVERFACES-2040 will fix (at least a part of) JAVASERVERFACES-1985. It does not remove the "hack approach" but the components will not be recreated and the "listener hack" will only executed once.

Manfred Riem added a comment - 27/Jun/12 04:38 PM

Using the attached example I am unable to reproduce this on 2.1.11

Mathias Werlitz added a comment - 02/Jul/12 09:36 AM

Yes, it seems this issue has been fixed with 2.1.11.