axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <gdani...@macromedia.com>
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)

--G

----- Original Message -----
From: "Glen Daniels" <gdaniels@macromedia.com>
To: <axis-dev@xml.apache.org>
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
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