Details
-
Type:
Improvement
-
Status:
Reopened
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: core
-
Labels:None
-
Number of attachments :
Description
I am continuing to make JiBX work properly with streaming XML. I ran into a problem, which I will describe here:
Let's say that I have a streaming xml as follows:
<stream>
<features>
<starttls><required/></starttls>
</features>
...... keeps going until communication closes....
</stream>
I have created a custom unmarshaller for <starttls>. <features> is specified in the binding file and the unmarshaller is generated by the binding compiler.
Since this is a streaming xml, after </features> is received, the </features> end tag is the last to be sent. There may be other data coming afterwards but </stream> is the last tag to be received to end the document.
The problem is that the generated unmarshalling code for the <features> element is something like this:
parsePastStartTag(null, "features");
//retrieve unmarshaller for <starttls>
//unmarshall <starttls>
parsePastEndTag(null, "features");
The last line of code is what causes the problem. By using parsePastEndTag(), the generated code will try to read past the end tag AND advance to the next major tag event (parsePastEndTag() first calls toEnd() and subsequently calls advance()). The advance() method hangs my code because it is continually trying to read data from the socket's input stream. However, there is nothing to read, so it tries forever.
The reason is that the remote entity only sends data up to the character '>' of "</features>".
My proposal is that the generated unmarshalling code should use toEnd() rather than parsePastEndTag(). This should not be a problem for subsequent unmarshalling of other elements because isAt() is usually called first anyways, which will advance the parser position to the next tag, essentially doing something similar to parsePastEndTag().
JiBX wasn't intended to support streamed document fragments of this type, so I can't see this as an error. Your suggestion makes sense and seems reasonable. Right now I'm not making any significant changes until after the 1.0 production release, but we can look into the change once that is done.
At least for now, the way to handle this is to use a custom unmarshaller for the collection of repeated items. That way your unmarshaller can control the order of parser requests.