You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gd...@macromedia.com> on 2001/04/24 06:55:02 UTC
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
Re: Some source
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Glen Daniels wrote:
> 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.
....
> Please take a look, and offer fixes, comments, and general opinions!
hi,
i think that it would be very beneficial to have Message abstraction and ability to
plugin different underlying implementations for Message interfaces (and it seems
Message interface is already in repository in package org.apache.axis.message).
so it would be good if your implementation of the message layer could be exchanged
with other Message implementation (even in runtime). to make sure that Message
abstraction can handle such operation it is very important to have more than one
underlying message implementation. i would be interested in writing XPP underlying
implementation for org.apache.axis.message.Message interface and it would give exactly
the same features (for example replaying SAX2 stream) but would not require extra
thread....
however to do it cleanly there must be a complete separation between interfaces and
underlying implementation requiring factory classes and not requiring concrete class
implementations when processing SOAP requests, for ex. org.apache.axis.message.RPCBody
is a concrete class and it is used in org.apache.axis.clientHTTPCall ...
thanks,
alek
> 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.
ps. just one more remark in: interface org.apache.axis.encoding.Deserializer method
public Object deserialize(MessageElement element, TypeMappingRegistry tmr);
there is need for a ontext information to handle multi-refs. such context should
include list of known so far mappings id->Message.
handling forward hrefs is more complex - you will need to ask parser to get you
message with given id from incoming stream ...
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)
Re: Some source
Posted by Glen Daniels <gd...@macromedia.com>.
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" <gd...@macromedia.com>
To: <ax...@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
>
>
>
Re: Some source
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Hi Glen,
I haven't gone thru the code yet, but I'd like to give a BIGGG +1
to moving forward on a sax-based implementation! I think we have
finally settled in on the right direction for axis .. :-).
One quick concern: Its not clear to me whether the two-thread
approach is still in use. If so I think we still have a non-starter.
Sorry .. no +1 in that case.
I would control the urge to be flexible vs. picking one thing to
move ahead with. Things like "our own thread pool" scare the hell
out of me ..
Sanjiva.
----- Original Message -----
From: "Glen Daniels" <gd...@macromedia.com>
To: <ax...@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
anh
> 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
>
>