If the schema restricts a data type, then you have to validate the input or output (input at the server, output at the client). Most (all?) service stacks will not validate by default. I have never seen generated stubs do anything with this. To my knowledge, you would need to use a service with "document" binding (rpc binding does things that make it impractical or impossible to validate against a constant schema, I think). Then you'll want an in-handler (at the server) or an out-handler (at the client) that takes the relevant part of the body of the SOAP message and validates against the schema you have. You had better have a schema-first mindset, because validating against the schema that's present in the WSDL will prove technically challenging (at best), I believe.
Are you comparing CXF to another stack that exhibits the behavior you're looking for? Cheers, Brice On 5/24/07, Feng Zhang <[EMAIL PROTECTED]> wrote:
Dear CXF team: After investigating, I think this is a bug. For the CXF helloworld example, there is a restiction on greetMe request type of maxlength=30 in the helloworld wsdl file, after wsdl2java, this restriction is not translated into java code or any mechanism to enforce it. So when I use soapUI to test the greetMe operation, no fault thrown when I type in 40+ long characters. The service behaves to ignore the initial contract with the length restriction in wsdl. Also, my soapUI says "initializing SSL" when connecting to the helloworld.wsdl, which puzzeled me, I didnot see anything related to SSL in the helloworld.wsdl. Please help on this if you could. Thanks in advance! Sincerely Feng
-- Brice Ruth Software Engineer, Madison WI
