ws-wsif-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony Elder" <ant.el...@uk.ibm.com>
Subject Re: [wsif] generic type mapping [Re: bug 16485 [BeanDeserializer error when XML element starts with a capital letter]]
Date Wed, 19 Feb 2003 17:11:50 GMT

I think the WSIF mechanism for mapping types is a separate issue to this
problem. Which ever mechanism WSIF uses the current WSIF AXIS provider
still wont work when element names start with a capital letter.

As no one is suggesting any way to overcome this, I'm becoming more tempted
to have the WSIF AXIS provider used a patched version of the AXIS bean
serializer which ignores the case of the 1st character of an element name.

       ...ant

Anthony Elder
ant.elder@uk.ibm.com
Web Services Development
IBM UK Laboratories,  Hursley Park
(+44) 01962 818320, x248320, MP208.


Aleksander Slominski <aslom@cs.indiana.edu> on 19/02/2003 16:27:08

Please respond to axis-dev@ws.apache.org

To:    wsif-dev@ws.apache.org
cc:    axis-dev@ws.apache.org
Subject:    Re: [wsif] generic type mapping [Re: bug 16485
       [BeanDeserializer error when XML element starts with a capital
       letter]]



Anthony Elder wrote:

>I think this is getting a little confused.
>
>I don't think this is to do with type mapping specifically. WSIF already
>has mechanisms for user type mappings, this problem happens when the XML
>type - Java class has been correctly established, and a SOAP response is
>being deserialised into a Java object - its the individual fields within
>that which need to be mapped, and thats what AXIS uses the TypeDesc
>information for.
>
Ant,

i believe that current mechanism is too simple and do not address needs
of more demanding WSIF users.

>If AXIS was not used to generate the beans from the WSDL, (perhaps from
the
>JAXB jxc, or the WASP WSDLCompiler, neither of which use TypeDesc) then
the
>bean will not work with the WSIF AXIS provider.
>
in my opinion that indicates that WSIF is not very flexible and
currently is dependent on AXIS and WSDL2Java.

i think that we need to look to make WSIF to work with other approaches
to databinding as long as they can be made to work with WSLD4J.

>What Jacques-Olivier originally pointed out was that  this makes WSIF
>dependant on AXIS being used to generate the beans and thus the client
code
>dependant upon the chosen binding,  and this breaks the WSIF being binding
>independent philosophy.
>
>Actually the above scenario of using JAXB or WASP would work unless any of
>the XML elements have names which start with a capital letter and this is
>what I think makes it seem like a bug somewhere. If the XML had a
>completely different name than the Java class field I  think it would be
>fine that it didn't work, but when just the case of the 1st character
>breaks it, it somehow makes it seems like a special case that should be
>tolerated.
>
>So as I see the options are:
>1 - call this a limitation and do nothing
>2 - design a way to add the required TypeDesc info to the WSDL binding and
>get the WSIF AXIS provider to somehow get that from the binding and tell
>the AXIS BeanDeserializer about it.
>3 - make the case of the 1st character of XML names a special case that
>should be tolerated by the WSIF AXISProvider
>
>Does this sound right or have I misunderstood something?  Are there any
>other options?
>
option 2 looks to me worth pursuing to get WSIF to be easier to
integrate with other databinding solutions - we should not make WSIF too
dependent on AXIS but rather keep possible to add other SOAP or XML
providers (like for example XML RPC).

thanks,

alek

--
"Mr. Pauli, we in the audience are all agreed that your theory is crazy.
What divides us is whether it is crazy enough to be true." Niels H. D. Bohr






Mime
View raw message