You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-user@ws.apache.org by "Vinh Nguyen (vinguye2)" <vi...@cisco.com> on 2007/06/29 02:47:44 UTC
empty vs invalid element
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.
Re: empty vs invalid element
Posted by Daniel Jemiolo <da...@us.ibm.com>.
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\)" <vi...@cisco.com> 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.
>
RE: empty vs invalid element
Posted by Daniel Jemiolo <da...@us.ibm.com>.
Muse's XML parsing code treats the empty element and non-existent element
the same during parsing - it's a null reference. Check out
XmlUtils.getElementText(QName) and see how it treats non-existent and empty
elements.
Dan
"Vinh Nguyen \(vinguye2\)" <vi...@cisco.com> wrote on 06/28/2007
08:56:28 PM:
> As an added note, if a non-java client sends a SOAP request to invoke
> the Subscribe operation and does pass empty elements for parameters that
> should be null, I am wondering how the Muse message handlers will handle
> this. Only then will we all be in the same boat:)
>
>
> -----Original Message-----
> From: Vinh Nguyen (vinguye2)
> Sent: Thursday, June 28, 2007 5:48 PM
> To: muse-user@ws.apache.org
> Subject: empty vs invalid element
>
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
RE: empty vs invalid element
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
As an added note, if a non-java client sends a SOAP request to invoke
the Subscribe operation and does pass empty elements for parameters that
should be null, I am wondering how the Muse message handlers will handle
this. Only then will we all be in the same boat:)
-----Original Message-----
From: Vinh Nguyen (vinguye2)
Sent: Thursday, June 28, 2007 5:48 PM
To: muse-user@ws.apache.org
Subject: empty vs invalid element
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org