Hi Michael,
Thanks for your reply.
I think you are right, that I was not registering an error handler.
Below are the latest findings from my code (with the modifications, as
per your suggestions).
In my main driver class (using which I am testing an end to end
validation process), I do something like (now I register an error
handler) following:
public class XMLSchema11Test implements ErrorHandler {
// some code
Validator v = s.newValidator();
v.setErrorHandler(this);
// some code
public void error(SAXParseException exception)
throws SAXException {
throw exception;
}
public void fatalError(SAXParseException exception)
throws SAXException {
throw exception;
}
public void warning(SAXParseException exception)
throws SAXException {
throw exception;
}
}
In the 'endElement' method of, XMLSchemaValidator.java I do:
if (assertionProcessor != null) {
try {
assertionProcessor.endElementDom(element);
} catch (Exception ex) {
throw new XNIException(
"error occured while evaluating assertions", ex);
}
}
I have to write, try/catch block here because some statements in
'endElementDom' method of class XMLAssertPsychopathImpl.java can throw
an exception.
Please note, that I am now passing the exception object 'ex' to the
higher API layers (earlier I wasn't doing this, as you pointed). Do
you think this is, OK?
In the method, 'endElementDom' of XMLAssertPsychopathImpl.java, I do
something like:
try {
ResultSequence rs = eval.evaluate(xp);
boolean result = false;
// set value to result. some code here to do this.
if (!result) {
String typeName = validator.fCurrentPSVI.getTypeDefinition()
.getAnonymous() ? "anonymous type"
: validator.fCurrentPSVI.getTypeDefinition().getName();
validator.reportSchemaError("cvc-xpath.3.13", new Object[] {
element.rawname,
assertImpl.getTest().getXPath().toString(), typeName });
}
}
catch(Exception ex) {
String typeName = validator.fCurrentPSVI.getTypeDefinition()
.getAnonymous() ? "anonymous type" : validator.fCurrentPSVI
.getTypeDefinition().getName();
validator.reportSchemaError("cvc-xpath.3.13", new Object[] {
element.rawname,
assertImpl.getTest().getXPath().toString(), typeName });
throw new XNIException("error occured while evaluating assertion",
ex);
}
Now when I run the validation process, I get error message as follows:
::file:///C:/xml/apache-xml-src/test.xml::15:8:-1:cvc-xpath.3.13:
Assertion evaluation ('1=2') for element 'root' with type 'anonymous
type' did not succeed.
Now the user has sufficient context information about the error. I
wanted to achieve this, and it seems to work fine.
Do you think, this flow is fine? Or, we could do it even better?
On Sun, Apr 12, 2009 at 1:54 AM, Michael Glavassevich
<[email protected]> wrote:
> Hi Mukul,
>
> Have you registered an error handler? I'm guessing by the result you're
> seeing that you haven't. By default (in other words when no error handler
> has been registered) the JAXP Valdiator is required to throw an exception
> [1] when a validation error is reported. If you want the validator to
> continue after the first error you need to have registered an error handler
> which permits that.
>
> Regarding the code you're writing... though I'm not sure for the need for
> the try/catch block around the call to evaluateXPathExpression() we
> shouldn't be catching exceptions from reportSchemaError(). Those are meant
> to be thrown from the schema validator all the way up to the API layer where
> they get converted to SAXExceptions. By catching it here and creating a new
> XNIException with only the error message we lose the location information
> (file name, line/column numbers) which would be useful for the application
> to determine where the error occurred.
>
> Thanks.
>
> [1]
> http://xerces.apache.org/xerces2-j/javadocs/api/javax/xml/validation/Validator.html#setErrorHandler(org.xml.sax.ErrorHandler)
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: [email protected]
> E-mail: [email protected]
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]