axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <gdani...@macromedia.com>
Subject Some source
Date Tue, 24 Apr 2001 04:55:02 GMT
OK, here's my current state with the SAX parsing stuff.  It's basically similar
to what was there before from James and I, except much more flexible and
functional.  I am not particularly happy with the cleanliness of this code, but
I wanted to get it out to you guys so you can tell me if I'm on the right
track.  A lot of niggly changes will be required to actually link this new
message model into the rest of the codebase (which is why I didn't check it
in), and I don't want to do them unless there's support for it.  One important
missing piece is another layer of message abstraction above this so that we can
get at the inputstream in the raw, and also parse MIME envelopes around the
XML.

Quickie summary : SAX parse the message on demand, stopping when we find
whatever was being looked for.  Separate out headers, bodies, and independent
elements, remembering the ID of each.  Headers also get mustUnderstand and
actor recorded, as well as any custom stuff the programmer desires.  Very basic
deserialization based on xsi:type QName works.

Essentially, we have this base handler, the SOAPSAXHandler.  He always gets the
SAX events as we parse, and then decides what to do with them.  He manages the
basic parsing state of the SOAP envelope, and knows if we're in the header, the
body, etc.  He also has the ability to set "target" elements and pause parsing
when those are hit, and to pass events on to a subsidiary handler.

Each time a sub-element of the <header> or <body> is encountered, there is a
lookup based on some information about the element (could be QName, position in
the document, service description, etc) to find a "sub-handler" which will
accept all the SAX events for the duration of this element.  This is to allow
two things.  First, recording the SAX event stream with an ElementRecorder.
Second, enabling the subclassing of the basic SOAPHeader class and parsing
directly into your new class (see DebugHeader for an example of this).

Right now, the body element always is an RPCElement, which gets parsed by an
RPCContentHandler.  This guy knows that all immediate children of the RPC
element are RPCParams, and each of THOSE might want to be parsed by some
deserializer it gets out of the TypeMapper.  If there's no deserializer, we
just use an ElementRecorder and let the app deal with it later.

The base handler is still funneling all the events through to the sub handler,
so he notices when the element in question closes, and pops the sub-handler
from off the top of a stack of them.

The next step I was going to take was one of two things - a) go build
serialization (replay the SAX events to a text writer, or custom XML generation
based on Java objects, or b) get deserializing ID/IDREFs working, which is
quite complicated with a SAX-based model.

Please take a look, and offer fixes, comments, and general opinions!

--Glen


Mime
View raw message