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\)" <[EMAIL PROTECTED]> 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: [email protected]
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

Reply via email to