Valid Elements after the first in-valid element are rejected as un-expected elements about jaxb-ri HOT 16 CLOSED

• Issue Imported From: javaee/jaxb-v2#20
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot
• Original Issue Closed By:@glassfishrobot

from jaxb-ri.

@glassfishrobot Commented
Reported by gmunamala

from jaxb-ri.

@glassfishrobot Commented
kohsuke said:
I wrote the following test to reproduce the problem, but it seems to be working
fine here.

Could you show me the content model you defined, and the instance you used?

from jaxb-ri.

@glassfishrobot Commented
kohsuke said:
Created an attachment (id=15)
A test case I wrote that shows the RI is working fine.

from jaxb-ri.

@glassfishrobot Commented
kohsuke said:
Changing it to P3.

Since this isn't a violation of the spec, I don't think this should be P1.

from jaxb-ri.

@glassfishrobot Commented
kohsuke said:
The author sent me the schema privately.
The problem is that he has a definition like this:

Unmarshalling is a cooperative process among various schema blocks. Each block
is responsible for unmarshalling its own portion, delegating the control to a
child block when appropriate, and returning the control to the parent at the
right moment.

When an instance like comes, the foo block is responsible for
"consuming" , and then as soon as it sees , it knows it's time to
delegate to the child. The complexType1 then takes over the control,
unmarshalles , and then when it hits , it realizes that this isn't the
token it can consume. So it returns the control to the parent, which knows how
to consume it. So this process works very well.

One thing to note here is that the child "complexType1" doesn't know what the
parent can consume. So if it sees some unknown token and if it's in a state
where it can legally end the content model, it always returns the control to the
parent, assuming that the parent will be able to consume it.

So, when the instance is like , where it contains some
unknown element , then when the "complexType1" sees , it realizes that it
doesn't know how to consume this token. And it also realizes that since the
complexType1 is nullable (IOW it can be satisfied by the empty sequence), it can
legally assume that the parent should know how to handle it. That is indeed the
case if the schema were:

So it returns the control to the parent, in the hope that it can handle .
Since our parent "foo" doesn't know how to handle , it reports an error,
ignores this element. Unfortunately, by the time it sees , the control is
already returned to "foo", so even though could have been consumed by
"complexType1", it will be sent to the parent "foo" and got rejected.

That's why you see all the successive valid elements rejected.

Because of the way the unmarshaller works, this behavior is hard to change. What
I think you should do in this case is to set up a SAX filter that runs a
validator, and cut the unexpected elements. Then you can configure your chain
like this:

XMLPull --> Filter --> JAXB

This prevents JAXB from seeing invalid contents, and thereby allowing you to
avoid relying on a fragile error recovery behavior of JAXB.

To write this kind of a filter, you might be interested in JARV
(http://iso-relax.sourceforge.net/JARV/) or JAXP 1.3 validation API.

from jaxb-ri.

@glassfishrobot Commented
gmunamala said:
Thank you for taking the time to look into the
issue.

Based on your explanation, I believe the issue is a
PRIORITY-1 because the spec requires that the JAXB
implementation and I quote "enable multiple validation
errors and warnings to be processed during a single
operation invocation" as described in Page 27 of JAXB
Specification - Final V1.0.

The implementation needs to allow the application
to recover from a validation error and thus giving an
opportunity for the application to decide whether to
abort the process or continue.

Yes, we could use other techniques such as JARV so
the content model provided to JAXB is always correct.
However it defeats the very purpose of providing
setEventHandler mechanism for the application. The
implemetation at the minimum provides a way to process
more than one error.

Our current application need to process more than
10 million messages in a batch file, and one
un-expected element in one message should not halt the
entire process if all the other messages are perfectly
valid!

from jaxb-ri.

@glassfishrobot Commented
kohsuke said:
I still don't think it is P1. The spec does not require a recovery
from an error. The portion you quoted is a justfication of the design,
and in many circumstances we do recover from errors.

We do "allow the application to recover from a validation error and
thus giving an opportunity for the application to decide whether to
abort the process or continue."

It's just that there are certain errors we cannot nicely recover from.

Since there are many cases we can recover from, I don't think some
failures in error recovery would "defeats the very purpose of
providing setEventHandler mechanism for the application."

Also, in my example, the RI should successfully back in sync by the time
it sees . So it shouldn't cause your 10 million message processing
fail just because you have one error in one message.

from jaxb-ri.

@glassfishrobot Commented
anandvallam said:
Created an attachment (id=25)
test case

from jaxb-ri.

@glassfishrobot Commented
anandvallam said:
When unknown element such as appears in a complex element, rest of the
elements get Unexpected element errors too.

I have looked in to issue 29 fix (https://jaxb.dev.java.net/issues/show_bug.cgi?
id=29) and it is working as desired.

This did not complain on next elements in the item complex element.

Why is it working in case of test case for issue 29 and it isn't for other
cases?

Installation

1. Extract zip file into jswdp-1.5/jaxb/samples dir.
2. Run ant.

from jaxb-ri.

@glassfishrobot Commented
kohsuke said:
In 2.0 the unmarshaller is made much more robust, and it should be
able to always recover from errors like this.

from jaxb-ri.

@glassfishrobot Commented
File: CRC.zip
Attached By: anandvallam

from jaxb-ri.

@glassfishrobot Commented
File: test.zip
Attached By: kohsuke

from jaxb-ri.

@glassfishrobot Commented
Was assigned to jaxb-issues

from jaxb-ri.

@glassfishrobot Commented
This issue was imported from java.net JIRA JAXB-20

from jaxb-ri.

@glassfishrobot Commented
Marked as fixed on Friday, April 15th 2005, 9:05:13 am

from jaxb-ri.