Validate presence of required attributes in PersistentResourceXmlParser/Description ----------------------------------------------------------------------------------- Key: WFCORE-2260 URL: https://issues.jboss.org/browse/WFCORE-2260 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Brian Stansberry Assignee: Tomaz Cerar One disadvantage of moving away from hand coded parsers to PersistentResourceXmlParser/Description is the hand coded ones often had a bit of logic to confirm that all expected attributes were set and fail with XmlStreamException if not. The benefit of that vs failing in boot operation execution is the indication of where in the xml the problem is and the integration with VDX. See JBEAP-8437 for an example of where that no longer happens. Adding this kind of thing to PersistentResourceXmlParser/Description is a bit tricky since it's generic while the hand coded stuff could just be applied where it was easy for the author to understand. Things that generic support would need to understand: 1) Attributes with alternatives are not required if the alternative is set. 2) Whether persistence is all via xml attributes or whether elements are involved. IOW when should the check that all required things are set be performed? If all persistence is to xml attributes then it should be done once the start element is parsed, before child elements. But if child elements are involved, then this needs to be deferred. Or I guess repeated, with logic that recognizes it's possible a required attribute that is persisted as an xml attribute may have an alternative that is persisted as an element. Speaking more generally, Jeff Mesnil had the brainstorming thought that beyond specific logic for this it may be possible for PersistentResourceXmlParser/Description to do validation against schema. Plenty of issues to consider there, including how to deal with expressions. (It would be great if it were easy to ask an xml validator to just validate structure, but ignore whether attribute values match the schema rules. That would avoid the problem with expressions. We already validate all the attribute values.) This is NOT meant for WildFly Core 3.0.