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.
Regards
-W
On 28 November 2015 at 10:30, Sebastian Bathke <sebastian.bathke_at_gmail.com>
wrote:
> 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
>>>>>
>>>>>
>>>>
>>>
>>
>