[ http://jira.codehaus.org/browse/JIBX-60?page=all ]
Dennis Sosnoski updated JIBX-60:
--------------------------------
Priority: Minor (was: Major)
type: Improvement (was: Bug)
Assign To: Dennis Sosnoski
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.
> Generated Unmarshaller may not work with streaming XML
> ------------------------------------------------------
>
> Key: JIBX-60
> URL: http://jira.codehaus.org/browse/JIBX-60
> Project: JiBX
> Type: Improvement
> Components: core
> Versions: CVS
> Reporter: Chris Chen
> Assignee: Dennis Sosnoski
> Priority: Minor
>
>
> 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().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
jibx-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-devs
