Okay, I just spent some time looking into the code and found this is not a seam issue, but a hibernate issue. The ClassValidator does not support collections. In both the initialization method as well as the actual validation method, it applies the validation to the field class and the method return class. The short comming is that it doesn't check to see if the field type or property type is a collection.
So what happens is that the parent object is parsed and the fields. The field type is a List/Set/Map (either generic or not). The class validator validates "List", "Set" and "Map" instead of the objects that the collection contains. Proposal Initialize changes: * Change the ClassValidator to check for collections. * If property/field is a collection, then check the generic type to see what type the collection contains. * Recurse through as normal Proposal Validate changes: * Check for collections when the property/field value is retrieved * If a collection, iterate over the members (values for map) * validate each item in the collection (TODO: decide the path to the object, should it include some kind of index identifier? This would not work for map though) Once this is done for hibernate-annotations, then seam would need an update. The trick would be how to map the validation issues to component IDs. This isn't so easy. The dataTable reders children IDs with the index: myObjectId:0:myCollectionMemberId where 0 is the index. That means to attempt to find the invalid component, the path dataTable would have to have an ID equal to the collection name, then somehow identify the index (would be good if the classvalidator did this) and then try to find the component. Example: class User @Valid List addresses; May result in a validation issue with path like: user.addresses[5].street The ID's in JSF would be something like: myForm:addresses:5:street Where myForm is the form component id, addresses is the ID of the dataTable component 5 is the index in the collection street is the input text component ID with the invalid value Gavin, looks like you are the author of the ClassValidator, what impact would this cause on the validator? I think this should be acceptable, if the developer does not want to propagate validation into the collection, they simply should not mark the field/property as "@Valid". Without this code, the only way to validate children is to have to hand code a validate method for every property on every entity that has a collection to validate, definately more effort than to incorporate it in the classvalidator. I would really like to have this before middle March, and may be willing to help to speed this up (probably by submitting a patch if necessary rather than trying to get CVS all setup). Thanks, Andrew View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3924479#3924479 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3924479 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
