Thanks, that explains why things are done the way it is. However, even toggling won't help in my case since I wany any non-Axis client to be able to send request to my Axis C++ server. I have no guarantee on what the client will be sending and therefore we need to validate during both serializing and deserializing.
-Kamlesh --- John Hawkins <[EMAIL PROTECTED]> wrote: > I won't comment on the broken code but I will > comment on the reason why > max and min values on reply msgs aren't validated. > > The view was taken that the server was already going > to do validation and > therefore that the client could have a reasonable > trust in the values > coming across the wire. You can argue either way - > it would be ideal if > someone would write it so that validation could be > toggled - but there > were more important things to do at the time. > > regards, > John. > > > > > > Kamlesh kumar <[EMAIL PROTECTED]> > 18/09/2006 21:30 > Please respond to > "Apache AXIS C User List" > <[email protected]> > > > To > [email protected] > cc > > Subject > xsd deserialization for integer types broken > > > > > > > The xsd deserialization for integer types is awfully > broken. > > For instance, calling the getElementAsInt() API for > the XML fragment > > "<foo>30a</foo>" > > I would have expected it to either return 30 or > ideally throw an exception. Instead, I get a value > of > 300 :( > > Similarly, calling > > "<foo>30 </foo>" returns a value of 300 ! > > I think the following change might have introduced > this bug. > http://svn.apache.org/viewvc/webservices/axis/trunk/c/src/soap/xsd/Integer.cpp?r1=261408&r2=261497&diff_format=h > > > Further, why aren't we validating against the > maximum > and minimum value for each type ? > > For instance, getElementAsShort() for the XML > fragment > > "<foo1>32768</foo1>" returns -1. I would have > expected > AxisC++ to throw an exception saying it exceeds the > max value of short instead of silently returning > wrong > values. > > I am surprised why this bug hasn't been seen till > now. > > Regardless, I think it should be top priority to fix > this issue. > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
