I think whatever problems exist in the design of JAXM will eventually be worked out. My preference is to complete the plumbing. Until the JAXM issues are resolved, Axis could offer both an Axis-specific way of supporting document-based messaging and the JAXM way.
> -----Original Message-----
> From: Glyn Normington [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 21, 2002 10:01 AM
> To: [EMAIL PROTECTED]
> Subject: javax.xml.soap
>
>
> Before the beta, I started plumbing the javax.xml.soap
> interfaces into the
> Axis message classes such as javax.xml.soap.SOAPElement. I
> didn't get very
> far - MessageElement now implements SOAPElement. The reason
> was in order
> better to support a UDDI server based on Axis which needs to
> get involved
> in deserialisation. The javax.xml.soap interfaces are likely
> to be more
> stable than the corresponding concrete classes in Axis such as
> MessageElement.
>
> Since then I've read a number of disparaging remarks about
> JAXM and wonder
> if it is likely to fall into disuse.
>
> The options appear to be:
>
> 1. Complete the plumbing.
> 2. Rip out the current plumbing and do without separate interfaces.
> 3. Rip out the current plumbing and define separate
> interfaces analogous to
> the javax.xml.soap interfaces.
>
> I don't like 2 if, as appears to be likely, it will be useful
> to expose the
> classes/interface as published Axis externals.
>
> 3. would give us more freedom and might be the best option
> *if* JAXM is on
> the way out.
>
> Thoughts?
>
> Glyn
>
***************************************************************************************
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
***************************************************************************************
