users@jaxb.java.net

Re: Reused UnmarshallingContext omits errors when errorsCounter is exceeded

From: Sebastian Bathke <sebastian.bathke_at_gmail.com>
Date: Sat, 28 Nov 2015 11:33:54 +0100

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 <sebastian.bathke_at_gmail.com>:

> Hi,
>
> 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
>
> @Wolfgang
> 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:
> https://issues.apache.org/jira/browse/CXF-2455
> But this seems to reuse the same jaxb unmarshallingContext what isn't
> recommended according to jaxb documentation:
> https://jaxb.java.net/guide/Performance_and_thread_safety.html
>
> 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.
>
> Sebastian
>
>
> 2015-11-28 7:20 GMT+01:00 Wolfgang Laun <wolfgang.laun_at_gmail.com>:
>
>> 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 <deantaia_at_gmail.com> 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)
>>>
>>>
>>> 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
>>>
>>>
>>> ... so is this the error you are getting ?
>>>
>>> dean
>>>
>>> On Fri, Nov 27, 2015 at 3:15 PM, Dean Tidwell <deantaia_at_gmail.com>
>>> wrote:
>>>
>>>> Sebastian,
>>>> hi, I am new to JAXB but I will clone your project and look at it
>>>> through my Java eyes.
>>>> - dean
>>>> Michigan
>>>>
>>>> On Fri, Nov 27, 2015 at 2:59 AM, Sebastian Bathke <
>>>> sebastian.bathke_at_gmail.com> wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> 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.
>>>>>
>>>>> Jaxb 2.2.11
>>>>>
>>>>> 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?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Sebastian
>>>>>
>>>>>
>>>>
>>>
>>
>