[ http://jira.codehaus.org/browse/JIBX-60?page=all ]
Dennis Sosnoski resolved JIBX-60:
---------------------------------
Resolution: Fixed
Fix Version: CVS
I bit the bullet and made this change, since it was also necessary to fix
problems with reporting the wrong element name on "expected end tag XXXX, found
start tag YYYY" errors.
> 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
> Fix For: CVS
>
>
> 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.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jibx-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-devs
