1. There is much debate on this, and unfortunately there is no official answer. The WS-* specs often use no element, but an empty element is much easier for frameworks such as Muse. As a general rule, wsdl2java generates a parameter even if it's optional, and you can check if the empty element in your method implementation; this allows the reflection-based router to get the right Java method every time. In the case of the WS-* implementations, we sometimes have special MessageHandlers that will take the optional/missing parameters into account.
2. If your parameter has nillable="true" in the XSD, then its expected you know what to do with a null parameter. If not, then you should throw a fault. 3. As I implied in #1, there is an inconsistency between generated clients and the WS-clients. This is because the design of many of the WS-operations does not lend itself to robust code generation. There are just too many cases in XSD/WSDL - we'd be working on it forever. That's why we came up with the WSDL conventions that are doc'd in the reference manual - to make sure people knew how to express their types/concepts so that our code generator could handle them. The ReflectionMessageHandler is used for what we consider to be well-formed, 'normal' WSDL, and the specialized ones are used to handle WS-operations that are a bit too flexible. Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 06/28/2007 08:47:44 PM: > This issue is related to a JIRA I opened previously: > MUSE-238-ReflectionProxyHandler creates an Element even for a null > parameter. > > 1) What's the proper way for a client to send a null parameter? Do they > send an empty element (i.e. <MyElement/>), or no element at all? > > 2) How is a server application supposed to handle a null parameter? An > empty element can be interpretted as null or invalid. > > There seems to be an inconsitency in using the Muse client classes. For > the generated proxies, null parameters are sent as empty elements, but > for the serializers I must create on the server side, I can't tell if > the element should be null or invalid. > > Yet, for Muse's own client classes, null parameters are sent by not > specifying the element at all. For example, > NotificationProducerClient.subscribe() will not send the Topic element > if it is null. Then on the server side, the Subscribe operation has its > own message handler which checks for missing elements and interprets > them as null. > > So I'm confused if we should follow Muse's pattern by creating > proxy/message handlers for each operation (which is very cumbersome and > has a large overhead), or use the default ReflectionProxyHandler and > ReflectionMessageHandler which Muse doesn't even use for its own > operations. >
