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 10:27:03 GMT

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.

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.

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?

       ...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 18/02/2003 19:56:48

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

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



Jacques-Olivier Goussard wrote:

>I'm a bit lost here. If WSIF is wsdl oriented and java based :),
>then isn't the mapping always from xml schema to java (and reverse) ?
>Sorry for the question, but I only used AXIS, EJB and Java providers
>yet.
>
hi,

i agree that it is confusing what is essentially model i have in mind is
that you start with Java objects you put to WSIFMessage then java
objects (identified by FQN)  needs to be mapped (see
WSIFService.mapType) to XML data type (identified by QName) and that is
then mapped by WSIF provider to its specific format. when provider is
receiving data the process is essentially reversed.

i hope that it makes easier to understand how WSIF mappings works.

thanks,

alek

>     /jog
>
>
>
>>-----Original Message-----
>>From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
>>Sent: Tuesday, February 18, 2003 2:07 PM
>>To: wsif-dev@ws.apache.org
>>Subject: Re: [wsif] generic type mapping [Re: bug 16485
>>[BeanDeserializer error when XML element starts with a
>>capital letter]]
>>
>>
>>Jacques-Olivier Goussard wrote:
>>
>>
>>
>>>That's the whole point of dynamic invocation...You do not
>>>need a stub to invoke the operations. But I guess you have
>>>a point here: patching AXIS is probably not enough, WSIF
>>>should have a way to specify serializers, which could probably
>>>be used for streaming in the case of AXIS/SOAP and in place
>>>of the <format:typeMapping>  for the EJB and java bindings.
>>>
>>>
>>>
>>hi Jacques-Olivier,
>>
>>i think that we should keep in mind that WSIF can be used to
>>invoke not
>>only XML oriented services so any generic serializer should
>>be carefully
>>designed to work with EJB, Java and other WSIF providers. also it
>>probably should fit into WSIF model that is WSDL driven so
>>all mappings
>>should be derived from information provided in WSDL file and
>>be either
>>provider specific (the way you propose) or provider
>>independent (that is
>>what i was thinking) or both ways can be supported too.
>>
>>thanks,
>>
>>alek
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Glen Daniels [mailto:gdaniels@macromedia.com]
>>>>Sent: Tuesday, February 18, 2003 1:16 PM
>>>>To: 'axis-dev@ws.apache.org'; wsif-dev@ws.apache.org
>>>>Subject: RE: [wsif] generic type mapping [Re: bug 16485
>>>>[BeanDeserializer error when XML element starts with a
>>>>capital letter]]
>>>>
>>>>
>>>>
>>>>Hola ant, everyone:
>>>>
>>>>I'm a little confused here.  Could you please give me a usage
>>>>scenario for what you're talking about?  Why are people
>>>>trying to tie apparently unrelated JavaBeans to XML
>>>>serializations?  It seems like either the schema will be
>>>>built from the Java class to begin with, or the Java class
>>>>will be built from the schema to begin with... any other
>>>>pattern a) seems odd, and b) requires some kind of metadata
>>>>to map the XML to the Java (otherwise, what do you do when
>>>>the bean has field "name" and the XML has field "moniker"?
>>>>Case-changing won't help you there...).  How do these classes
>>>>get created?
>>>>
>>>>Trying to grok the situation,
>>>>--Glen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Anthony Elder [mailto:ant.elder@uk.ibm.com]
>>>>>Sent: Tuesday, February 18, 2003 12:20 PM
>>>>>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]]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>From the comments Glen added to the bugzilla record the only
>>>>
>>>>
>>>>>way to do this
>>>>>if the bean itself doesn't have the TypeDesc info is to have
>>>>>another class
>>>>>named as the bean class name appended with "_Helper". (Glen,
>>>>>please leap in
>>>>>here if there is another way to do this)
>>>>>
>>>>>As WSIF is designed to be dynamic  and we don't know what
>>>>>WSDL will be used
>>>>>or what bean classes are available before hand, for each
>>>>>operation we'd
>>>>>have to parse the WSDL schema, find the associated beans,
>>>>>check for setters
>>>>>for each field, if we don't find one, check again with a name
>>>>>starting with
>>>>>a lowercase letter, and if that finds one create a TypeDesc
>>>>>class for it.
>>>>>Perhaps we could do that with BCEL.
>>>>>
>>>>>Even if there is a way to register the TypeDesc info with
>>>>>
>>>>>
>>>>>
>>>>>
>>>>AXIS without
>>>>
>>>>
>>>>
>>>>
>>>>>generating a class on the fly, this is a lot of work to be
>>>>>doing for each
>>>>>WSIF operation.
>>>>>
>>>>>Another option would be for WSIF to have a patched copy the AXIS
>>>>>BeanSerializer code which has the fix to try with a lowercase
>>>>>1st letter.
>>>>>
>>>>>      ...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 18/02/2003 16:12:01
>>>>>
>>>>>Please respond to wsif-dev@ws.apache.org
>>>>>
>>>>>To:    wsif-dev@ws.apache.org
>>>>>cc:
>>>>>Subject:    [wsif] generic type mapping [Re: bug 16485
>>>>>[BeanDeserializer
>>>>>      error when XML element starts with a capital letter]]
>>>>>
>>>>>
>>>>>
>>>>>hi,
>>>>>
>>>>>why do you think that code generation is required?
>>>>>
>>>>>AFAIK there would be no code generation but just converting in AXIS
>>>>>provider form WSIFTypeDesc (or something like that) into AXIS
>>>>>TypeDesc?
>>>>>
>>>>>that would allow other WSIF providers to do do similar
>>>>>
>>>>>
>>>>>
>>>>>
>>>>things: declare
>>>>
>>>>
>>>>
>>>>
>>>>>mappings in provider specific way based on WSIFTypeDesc. we
>>>>>already have
>>>>>WSIFService.mapType()/WSIFDynamicTypeMap and we may just need
>>>>>to take it
>>>>>one step further and allow more fins grained mapping control?
>>>>>
>>>>>thanks,
>>>>>
>>>>>alek
>>>>>
>>>>>Owen D Burroughs wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I don't think that WSIF should be generating code "on the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>fly". This would
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>be very slow.
>>>>>>
>>>>>>Owen
>>>>>>
>>>>>>
>>>>>>
>>>>>>|---------+---------------------------->
>>>>>>|         |           Anthony          |
>>>>>>|         |           Elder/UK/IBM@IBMG|
>>>>>>|         |           B                |
>>>>>>|         |                            |
>>>>>>|         |           18/02/2003 12:04 |
>>>>>>|         |           Please respond to|
>>>>>>|         |           wsif-dev         |
>>>>>>|         |                            |
>>>>>>|---------+---------------------------->
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>--------------------------------------------------------------
>>>>>--------------------------------------------------------------
>>>>>----------------------|
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>|
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>|
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>|       To:       wsif-dev@ws.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>|
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>|       cc:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>|
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>|       Subject:  bug 16485
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>|
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>|
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>|
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>|
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>|
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>--------------------------------------------------------------
>>>>>--------------------------------------------------------------
>>>>>----------------------|
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>A while ago a user reported a problem with WSIF using the
>>>>>>
>>>>>>
>>AXIS bean
>>
>>
>>>>>>serializer when the schema used names which start with a
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>capital letter:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>http://marc.theaimsgroup.com/?l=axis-user&m=104203857924370&w=2.
>>>>>>
>>>>>>I raised an AXIS  bugzilla about it:
>>>>>>
>>>>>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16485
>>>>>>
>>>>>>which has now been closed as working as designed. I guess
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Glen is right in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>what he says about the reasons for closing this, but as the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>original user
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>pointed out, it seems wrong for WSIF to be dependent on the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>AXIS specific
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>TypeDesc info:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I would have expected WSIF not to be AXIS dependant for
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>the complex
>>>>
>>>>
>>>>
>>>>
>>>>>>>type mapping, as it makes the client code dependant upon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>the chosen
>>>>
>>>>
>>>>
>>>>
>>>>>>>binding. From the code - but I'm really new to WSIF so
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>there may be
>>>>
>>>>
>>>>
>>>>
>>>>>>>better ways - it seemed to me that the AXIS provider
>>>>>>>
>>>>>>>
>>would have to
>>
>>
>>>>>>>generate the TypeDesc at runtime (i.e., doing WSDL2Java job) and
>>>>>>>use it to create the proper BeanDeserializers.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>I'm not sure how easy it would be for WSIF to generate the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>TypeDesc on the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>fly. What does anyone else think about this?
>>>>>>
>>>>>>     ...ant
>>>>>>
>>>>>>Anthony Elder
>>>>>>ant.elder@uk.ibm.com
>>>>>>Web Services Development
>>>>>>IBM UK Laboratories,  Hursley Park
>>>>>>(+44) 01962 818320, x248320, MP208.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>--
>>>>>"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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>--
>>"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
>>
>>
>>
>>
>>

--
"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