we just stumbled over this as an adjacent system upgraded its schema containing new elements.
At first we got the expected "javax.xml.bind.UnmarshalException: unexpected element" errors but suddenly they vanished and everythin worked as if the schema violation wouldn't be present, but it still was.
Debugging this case lead to the UnmarshallingContext#shouldErrorBeReported method and the errorCounter. I wonder whether this is a feature or a bug, why would jaxb ever stop to report errors for new messages only because previous ones already had errors? We are using cxf jaxws clients that reuses the UnmarshallingContext instance.
I prepared a simple project to demonstrate the issue: https://github.com/megglos/cxfIncomaptibleServerSample . Please see the SpringClient class it sends requests to a server that responds with a different element than expected, after the 10th requests it stops throwing errors because of the errorCounter feature and the catch isn't reached anymore.
Would greatly appreciate any clarification to this, is it a bug or a feature if the latter what's the reason? Or should cxf just simply not reuse the unmarshallingConext for multiple request/response transactions?
Sebastian,hi, I am new to JAXB but I will clone your project and look at it through my Java eyes.
On Fri, Nov 27, 2015 at 2:59 AM, Sebastian Bathke <[hidden email]> wrote:
okay, I am here (see below) with your project using two command windows and mvn -Pserver (command window one) mvn -Pclient (command window two)... so is this the error you are getting ?
Caused by: javax.xml.bind.UnmarshalException: Errors limit exceeded. To receive all errors set com.sun.xml.bind logger to FINEST level.
... 42 more
should always happen, api is incompatible
Invoking greetMe... 10
This should never get reached, but does after com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext#errorsCounter is exceeded
Server responded with: null
On Fri, Nov 27, 2015 at 3:15 PM, Dean Tidwell <[hidden email]> wrote:
Note that JAXB is tolerant by definition. And that's why XML Schema validation must be used to learn reliably about deviations from a schema.-W
On 27 November 2015 at 22:11, Dean Tidwell <[hidden email]> wrote:
thank you guys for having a look into this that fast :)
@Dean yes, as I tried to indicate it by the sysout, I would expect the operation to always fail because of the incompatible schema
You pointed me in the right direction, the issue (as I see it) seems to be on the cxf client side. CXF has a "basic" validation active by default:
But this seems to reuse the same jaxb unmarshallingContext what isn't recommended according to jaxb documentation:
From my perspective the unmarshallcontext shouldn't get reused between calls of the cxf client "each time you need to unmarshal/marshal/validate a document. Just create a new Unmarshaller/Marshaller/Validator". I raise a question or Jira issue at CXF.
2015-11-28 7:20 GMT+01:00 Wolfgang Laun <[hidden email]>:
To complete my side notes: If a certain error is thrown due to XML response data, the connection might be considered as "flawed" and not used any more - possibly an extreme reaction. But if you continue beyond the first: why don't you continue beyond the tenth? - If segregation of deviating responses is required as an acceptable solution, then, of course, using a new context each time or (as Dean has pointed out) setting the log level to FINEST would be the way to go.
On 28 November 2015 at 10:30, Sebastian Bathke <[hidden email]> wrote:
In reply to this post by Sebastian Bathke
Having another look on jaxb's UnmarshallingContext I found that the errorCounter is a static field, so new UnmarshallingContexts won't help at all with this.
From looking at where #shouldErrorBeReported is called it seems like unexpected elements as well as unknown xsi types are just treated like that. "Report them 10 times, after that just ignore them." So they are considered kind of not that important and basically ignored at production? Unexpected elements can just be ignored and unknown xsi types as well?
2015-11-28 10:30 GMT+01:00 Sebastian Bathke <[hidden email]>:
|Free forum by Nabble||Edit this page|