axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: Some source
Date Tue, 24 Apr 2001 16:39:52 GMT
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)



Mime
View raw message