[
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)
