Conceptional issues/questions

["Zolyomi Istvan (EXT-IT-Guru/Budapest)" <Ex...@nokia.com>]

Hi,

I didn't follow the exact changes in the repository, but fortunately the
apache modules I currently compiled do not segfault anymore. :)

After running some samples and examining the code architecture, I'd have
a few questions, and also some suggestions for features that would worth
support, IMHO. Sorry in advance, if I misunderstood something, I'm just
getting familiar with Axis C++ ...

1, Currently I could find no support in the WSDL2Ws tool for http
proxies. Because I'm sitting behind a company firewall, I'm effectively
unable to use it. (Perhaps this applies to the HttpTransport transport
handler in C++, too). Would it be difficult to add this feature?

2, As far as I could understand, the current XML parsing model is event
based: in your service, you tell through a DOM-like interface what kind
of elements you expect to come next (e.g. getElemenentAsInt() tries to
interpret the next parsed entity as an integer). For this, you have to
know the structure of the message in advance, what applies to generated
services, but not necessarily to handcrafted message filters (non-pivot
handlers). SOAP message headers seems to be an exception: the header
block is deserialized in whole and stored in a container, which can be
accessed later. Is there a way to access other parts of the message
similarly if needed?

3, Is there a way to access (parts of) SOAP messages in a raw (string)
form? This would be useful for e.g. logger handlers. The only
possibility for accessing some parts of the message seems to be the
getBodyAs...() functions, but these return encoded (Base64 and
HexBinary) strings and they are not currently implemented. You could
also get the whole message string if you use SimpleServer, but currently
it is broken. Is there any way to do this other than running a tcp/ip
sniffer tool?

4, I think there is a bug in the current src/soap/SoapDeSerializer.cpp.
In function getElementAsBoolean(), the current implementation for
Document/Literal case seems to return true for string value "false".

5, Currently every message handler gets a MessageData containing a
(de)serializer, which it can use to assemble or parse the message. As I
could understand, in the case of having several request handlers, every
handler has to re-parse the whole message for itself. It would be very
effective to have support for storing some kind of "parsing cache" (e.g.
a partial DOM tree) in MessageData. Thus only the first handler would
parse the message, all other handlers could use information gained from
the first parsing process. Unfortunately this seems to be tough to
implement, because a handler may _change_ the contents of the message:
the "cache" must be kept consistent.

I think these issues worth mentioning. Soon I start writing some sample
codes. I Hope we can use a stable release 1.1 very soon. :)
-- 

best regards

Istvan