[ https://issues.apache.org/jira/browse/NIFI-11156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688714#comment-17688714 ]
Adam Taft commented on NIFI-11156: ---------------------------------- Without arguing about the API decisions happening in all the xml processing code (which is a different discussion), agreed that unrolling the exception chain that starts with ProcessException is probably the smallest thing that ValidateXML could do. Somewhere around line 200 of ValidateXML.java you'd want to unroll the chain that is now an extra layer deep because of the ProcessException wrapper. Hopefully you'd find your way down to a meaningful SAXException, which includes the more useful error message via #getMessage(). The ideal situation is that we wouldn't be passing around validation errors as exceptions at all. I know this design originates from the JDK, but ideally one could pass a callback or some other reference to the SchemaValidator in order to do something better than just rethrowing checked exceptions as unchecked, which is all the "value" that ProcessingException is apparently adding. But that's probably a different overhaul and effort though, especially if we don't want to change anything related to SchemaValidator and StandardSchemaValidator nor any runtime exceptions that they throw. SchemaValidator could, for example, return a ValidationResult object, so that callers don't have to trap exceptions into AtomicBoolean state to decide if it "passed" or "failed" validation. That being said, rolling out the exception chain to eventually call getMessage() on the bottom-most exception is probably the most localized update to ValidateXML that would restore the original behavior. I agree with David on this assessment, probably the recommended approach for where it's at. If on the other hand, SchemaValidator wanted to be improved, adding a return value to it would be the most ideal situation, so that callers can definitively know if validation was successful and if not what type of error they might be dealing with. Using exceptions for control flow sucks. > ValidateXml Processor - validatexml.invalid.error = Validation failed > --------------------------------------------------------------------- > > Key: NIFI-11156 > URL: https://issues.apache.org/jira/browse/NIFI-11156 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions > Affects Versions: 1.19.1 > Environment: CentOS 7.5, RedHat 7.9 > Temurin - 11.0.17+8 > Reporter: Bilal > Priority: Minor > > _NiFi_ environment was upgraded from 1.15.1 to 1.19.1. The following > situation has occurred with the _ValidateXml_ processor: > _ValidateXml_ processor works correctly on 1.15.1 and > _validatexml.invalid.error_ attribute gives an detail information about the > error. > _ValidateXml_ processor works on 1.19.1 but _validatexml.invalid.error_ > attribute does not give an detail information about the _error. > validatexml.invalid.error_ attriubute only contains “{_}Validation failed{_}” > text. > Similar problem was talked in cloudera community and Eduu said that: > =========== > Hi > [@ChuckE|https://community.cloudera.com/t5/user/viewprofilepage/user-id/98065] > using NiFi 1.15.2 seems to add the error detail in the > "validatexml.invalid.error" attribute. > For example --> "cvc-minLength-valid: Value '' with length = '0' is not > facet-valid with respect to minLength '1' for type 'HotelCode" > This seems to be an issue starting from NiFi 1.16.3, maybe a bug? > You can use NiFi 1.15.2 or custom code as > [@SAMSAL|https://community.cloudera.com/t5/user/viewprofilepage/user-id/80381] > suggested. > =========== > Ref: [How to get the reason for invalid > XML|[https://community.cloudera.com/t5/Support-Questions/How-to-get-the-reason-for-invalid-XML/m-p/348767/highlight/true#M235443]] -- This message was sent by Atlassian Jira (v8.20.10#820010)