Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313166

Summary: [JSF2.0] False warning for h:commandButton in a composite
Product: [WebTools] Java Server Faces Reporter: Xiaonan Jiang <xiaonan_jiang>
Component: JSF ToolsAssignee: Gerry Kessler <gerry.kessler>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: david_williams, raghunathan.srinivasan, yurykats
Version: unspecifiedFlags: david_williams: pmc_approved+
raghunathan.srinivasan: pmc_approved? (naci.dai)
raghunathan.srinivasan: pmc_approved? (deboer)
raghunathan.srinivasan: pmc_approved? (neil.hauge)
raghunathan.srinivasan: pmc_approved? (kaloyan)
raghunathan.srinivasan: review+
Target Milestone: 3.2 RC2   
Hardware: PC   
OS: Windows XP   
Whiteboard: PMC_approved
Attachments:
Description Flags
Proposed solution none

Description Xiaonan Jiang CLA 2010-05-17 11:22:37 EDT 
Build Identifier: wtp 3.2

The following code is valid:

<composite:interface>
  <composite:actionSource name="button" />
</composite:interface>

<composite:implementation>
  <h:commandButton id="button" value="Submit" />
</composite:implementation>

but the jsf validator reports the following warning:
  "h:commandButton requires h:form ancestor"

Reproducible: Always
Comment 1 Gerry Kessler CLA 2010-05-17 14:59:03 EDT 
Created attachment 168800 [details]
Proposed solution

There is very little containment validation occuring at this time, and in the interest of removing false positives, this patch disables it.  There is now a check for a system property/env var of "jsfCoreEnableContainmentValidation".   If the property is found, the containment validation will occur in it's current form.

Bug 313221 has been created to track allowing adopters to replace the default containment validation.
Comment 2 Raghunathan Srinivasan CLA 2010-05-18 00:57:58 EDT 
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug"
(requested by an adopter) please document it as such. 
In a JSF 2.0 application, this bug will report multiple incorrect validation errors and there is no preference based option for the user to suppress it.
* Is there a work-around? If so, why do you believe the work-around is
insufficient? 
No reasonable workaround.
* How has the fix been tested? Is there a test case attached to the bugzilla
record? Has a JUnit Test been added? 
Manual testing
* Give a brief technical overview. Who has reviewed this fix? 
See  comment 1.
* What is the risk associated with this fix?
none
Comment 3 David Williams CLA 2010-05-18 01:14:17 EDT 
I'm wondering why logic is left in, if system or environment variable set? Do you expect people to use that? Or is is for some specialized debugging? If the former, wouldn't a product customization preference be better? If the latter, should it be documented as "property for debugging purposes only, will not be supported in future versions", or some such? 

Thanks for clarifying.
Comment 4 Raghunathan Srinivasan CLA 2010-05-18 11:25:09 EDT 
The containment logic in the current form is still valid, though in a limited set of use cases and has been left behind for users who have been relying on this validation. We will revisit this area in the next release to make it more extensible.
Comment 5 David Williams CLA 2010-05-19 20:07:09 EDT 
ty
Comment 6 David Williams CLA 2010-05-20 12:47:33 EDT 
since this isn't marked 'fixed' should it go to RC3? Or was it fixed? Or is a rebuild required?
Comment 7 Raghunathan Srinivasan CLA 2010-05-20 13:07:18 EDT 
We have not checked in the fix and we can push this to RC3 unless there is a rebuild of RC2.
Comment 8 Gerry Kessler CLA 2010-05-20 13:18:43 EDT 
Checked in for RC2
Comment 9 Raghunathan Srinivasan CLA 2010-05-20 13:27:39 EDT 
Released to RC2