axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <>
Subject Re: Some source
Date Tue, 24 Apr 2001 04:58:49 GMT
Btw, you'll need to drop this into the current axis framework to test it, as I
didn't include QName, Constants, etc. in the zip....(alternately you could just
copy those over into the right places)


----- Original Message -----
From: "Glen Daniels" <>
To: <>
Sent: Tuesday, April 24, 2001 12:55 AM
Subject: Some source

> OK, here's my current state with the SAX parsing stuff.  It's basically
> 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,
> 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
> missing piece is another layer of message abstraction above this so that we
> 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
> deserialization based on xsi:type QName works.
> Essentially, we have this base handler, the SOAPSAXHandler.  He always gets
> SAX events as we parse, and then decides what to do with them.  He manages
> basic parsing state of the SOAP envelope, and knows if we're in the header,
> body, etc.  He also has the ability to set "target" elements and pause
> 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
> lookup based on some information about the element (could be QName, position
> 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
> 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
> 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

View raw message