Java Reference
In-Depth Information
//Create marshaller
Unmarshaller um = ctx.createUnmarshaller();
//Create instance of schema...
//Create instance of our custom handler
MyHandler myHandler = new MyHandler();
//Add it to unmarshaller
um.setEventHandler(myHandler);
//...
Using this handler gives you the following output, indicating that you can't specify the same
prefix twice:
**** Got an Error of type
org.xml.sax.SAXParseException.javax.xml.bind.UnmarshalException
- with linked exception:
[org.xml.sax.SAXParseException:
Attribute "xmlns:b" was already specified for element "b:book".]
NOTE
Not all of the data is available for every invocation of the ValidationEventLocator . Depending
on the kind of validation, you may or may not be able to access certain fields. Validation during un-
marshaling will produce data regarding the XML source data, while ad hoc validation or validation
during marshaling will give you locator data referring to Java objects. For example, don't expect
much from the getLineNumber method in such a case.
ValidationEventCollector
As previously mentioned, the way that this validation handler works is to immediately halt
processing if an error or fatal error is encountered. This might be what you want in order to
optimize performance and avoid unnecessary work. You could reject a document out of hand
at the first error and instruct the user to fix the content before you'll add it to the body of a
SOAP message for transmission.
On the other hand, perhaps you are keeping track of how users invoke your service, and you
want to be able to collect more information behind the scenes. Perhaps you want to evaluate
the full array of warnings and errors before determining the appropriate action to take. You
might have self-correcting code that massages data upon receipt of a payload. That means that
you need to continue processing even though you have received warnings and errors. That's
where ValidationEventCollector comes in.
Search WWH ::




Custom Search