-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Samisa and all,
You have a very good point here, except that you started from the wrong class. The complete API for the users to use is the OperationClient API. But since most users, yes *most* user's concern is to send and receieve XML fragment which is supported in ServiceClient API. There are lots of things missing in ServiceClient. From the day one ServiceClient API was meant to be the simple API for simple work. Most of the users do not look at SOAP message. Especially because of J2EE containers users even do not look at the XML fragment. That is why we gave a convenient API on top of OperationClient. If you want to look at the SOAP message or if you want to change the engine or if you want to change MEP, then we consider that as an advanced operation which require him to use OperationClient. One can come-up with various use cases which seems simple to them and might wonder why it is not included in ServiceClient. The simple answer is Axis2 was there for a long time, more than 2 years and ServiceClient must have been there at least for 2 years, but we found out that users are satisfied with the existing way of only dealing with OMElement in and OMElement out. Again I totally agree with you that users need to face extra bit of hassle when they want to add little bit more to what they are using with ServiceClient, but that is intentional. Thanks, Chinthaka Samisa Abeysinghe wrote: > >>> Deepal Jayasinghe wrote: >> >> >>>>> Hi Jack , >>>>> If this is in the server side , you can get the message context and >>>>> from >>>>> that you can get the SOAP envelope and from the soap envelope you can >>>>> get the soap headers. >>>>> >>>>> If it is the in the client side , the the process is , >>>>> - First you get the last operation context from the service client >>>>> - and then follow the above steps. >>>>> >>> >>> That looks like too much work for me to get a simple thing done :( >>> Why not have some method like: >>> getLastResponseSoapEnvelope() >>> to service client API and do all the context access stuff within that >>> method ? >> >> >> Idea is cool I am +1 on doing that , but ... > >> One of the design goal of service client was to provide a convenient >> API for simple usage (cater for average users), and the assumption was >> that user only trying to send OM element and trying to get OM element . >> If you need to do advanced work like accessing SOAP headers , then you >> can use OperationClient. > > OK, cool, I forgot about operation client. However, there still remains > a minor concern about the usability/maintainability of the stuff. This > case is an ideal example - the use writes some code, and gets it working > - now wants to do more with the API, and he/she has to switch from one > API to the other to get the things done :( > > Samisa... > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUQifjON2uBzUhh8RAl3SAJ4uCtbs4pElSKfbr1eOQtvSoExRhgCfb438 2aPufLx7Sthf8JSgzpf3joQ= =6WJN -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
