StAX implementation 'bugs'

Question

Hi,
I'm trying out both the BEA reference implementation, and the weblogic implementation.
The reference implementation works well, except for a bug in parsing. I've noticed
that when an element contains only an entity reference as character data, it is
not detected. e.g.
<foo>
<bar>&</bar>
</foo>
Will result in START_ELEMENT, START_ELEMENT, END_ELEMENT, END_ELEMENT events and
does not produce an expected CHARACTERS event in the middle. I have not tested
this with the weblogic implementation yet.
As for the weblogic implementation, I'm having trouble using it in my streaming
XML application. I need to parse incoming XML as it is sent to me. Unfortunately
the weblogic implementation is evidently trying to fill a buffer on the initial
xmlInputFactory.createXMLStreamReader(). The call doesn't return until the buffer
is filled which will never occur in my case (the client sending XML to the server
waits for a response before sending more XML than the opening tag, and the server
needs to parse the opening tag sent by the client before it can generate that
response). Is there a way to tell the weblogic implementation to change it's buffer
size or, even better, to have it work like the reference implementation and parse
what it reads before trying to read more? Buffering will be handled externally
to the parser in my case so this forced buffering by the weblogic implementation
ends up being a major problem.
Thanks
-iain

Answer 1

Many thanks for the feedback!
Bruce
Iain Shigeoka wrote:
>
Bruce Stephens <[email protected]> wrote:
The StAX guru says:
It's not clear we can provide the requested behavior. The underlying
processor reads the stream to setup the state. The parser needs to read
ahead and no guaruntees are provided that say the underyling parser
won't
attempt to read ahead in the char stream.
If you could provide a simple reproducer for this issue it would be
appreciated.Hi,
The particular use-case here is to support IETF XMPP streaming XML:
http://www.ietf.org/html.charters/xmpp-charter.html
In particular a tcp/ip connection is made between a client and server. The client
sends an opening <stream> tag. The server must read that tag in, obtain information
from the tag's attributes, then reply with it's own opening stream tag <stream>.
The tag is not large in size but must be processed before more data is sent.
Conceptually the socket holds two streaming XML documents (one c-s and one s-c)
that are sent in a coordinate fashion (client sends some of it's xml, server reads
that bit then sends some of it's xml, etc). The reference implementation loads
it's buffer with the first read, then attempts to parse it before loading more
data. This works great for XMPP since participants send complete XML 'parts' (e.g.
the complete start tag, data to the next end tag, etc).
The BEA implementation keeps trying to load more data to fill it's buffer before
inspecting the data it has already read in. Thus it doesn't pull events as it's
read unless it can fill it's buffer first.
To replicate this, simply run the first simple xml printer example program from
http://www.xml.com/pub/a/2003/09/17/stax.html?page=1, substituting the reading
of a URL to the following:
create a server socket on port 5222
block on accept, when you get a connection
Read the xml from the connection
Now start that program, and run any XMPP/Jabber client against it. If you're on
Windows, I'd suggest Exodus http://exodus.jabberstudio.org/ because you can use
F12 to display a debug window showing the XML being sent and received. Alternatively,
just telnet to port 5222 on localhost to connect to your new server, and type
<stream>
If you use the reference implementation, you'll see the program spit out 'stream'
because it has seen it, and pulled the event. With the BEA implementation you'll
never see the opening tag because it will stay blocked trying to read and fill
it's buffer.
If the 'required to fill buffer before parsing' behavior of the BEA implementation
cannot be changed, can we have a way to set the buffer/read-ahead size? My streams
can be buffered externally so I'd then set the stax buffer to '1' and should get
the behavior I want.
I understand that this behavior is not required by the Stax spec so if you decide
not to support it in the BEA implementation I'd love to know so I can look for
an implementation that does.
Thanks
-iain