[ http://jira.codehaus.org/browse/JIBX-60?page=all ] Dennis Sosnoski reopened JIBX-60: ---------------------------------
Whoops, I take it back - the changed code still advances past the close tag, and that won't work in the situation described. One workaround is to add a comment following each of the streamed elements. Another approach is to handle the start and end tags for the streamed elements in your custom code, and use an abstract <mapping> with no extension mappings for the streamed object class. In the current code you can set a flag on the binding (force-classes="true") to generate marshaller/unmarshaller classes for abstract mappings of this type. The binding factory (which can now be accessed from the marshalling or unmarshalling context) provides a method to look up the mapping index for an abstract mapping, and the index can then be used to get the actual marshaller/unmarshaller class. Convoluted, but it works. > 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
