axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Jose <jamej...@in.ibm.com>
Subject Re: IHeaderBlockTest3
Date Sat, 26 Feb 2005 12:27:39 GMT
Hai,

 A modified version of the test is included in the test list.

Regards
James
--------------------------------------------------
James Jose
Messaging Clients Team, WMQDDC
IBM Software Labs, India
Direct: 91-80- 25094331  Ext :2331
E-mail: jamejose@in.ibm.com





John Hawkins <HAWKINSJ@uk.ibm.com> 
22/02/2005 21:52
Please respond to
"Apache AXIS C Developers List"


To
"Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
cc

Subject
Re: IHeaderBlockTest3







Having looked into this further I stick by my first statement. The testing 
we did in te other verssion of the method is now in place however, it does 
not fully test the very complex scenario which the test is attempting. 

I would rather we concentrate on de/serialisation issues and issues 
related to unsupported types etc. than rather complex user error issues. 
For now the doc and slightly upgraded testing is enough 








Roshan Weerasuriya <roshan@opensource.lk> 
22/02/2005 14:46 

Please respond to
"Apache AXIS C Developers List"


To
Apache AXIS C Developers List <axis-c-dev@ws.apache.org> 
cc

Subject
Re: IHeaderBlockTest3








hi John,

>This test attempts to set the same attribute in a headerblock element
>twice.

If the user attempt to add same attribute the method "createAttribute()"
will return NULL for all duplicate additions. I see this check in the
code.

Roshan

On Tue, 2005-02-22 at 13:50 +0000, John Hawkins wrote:
> 
> Hi Folks, 
> 
> this tests fails today. This test attempts to set the same attribute
> in a headerblock element twice. this is not allowed. Today we do no
> checking to see if it has already been set and thus we pass bad
> XMLfrom client to server. 
> 
> I'm not prepared to do the checking in the IHeaderBlock class to
> ensure that it checks before sending the msg over the wire. When e.g
> WAS sees the malformed message it returns back a good fault message
> saying what went wrong. i.e. the server in this case is checking. I
> suggest we document to the user what we have decided and then consider
> improving the object model so that we centralise this sort of checking
> in a later release. 
> 
> I'll do it now but any comments are welcome. 
> 
> 
> Not sure what to do about the test though. Can we remove it from the
> list but kep the test as it is a valid test if we supplied that level
> of function ? 
> 
> 
> regards, 
> John.



Mime
View raw message