Hi,
Echoing Glen's comments, I think the larger problem is that java<-->XML naming is ambiguous by definition, so it is impossible to work without metadata in the most general case. The first character uppercase problem is only one instance of the issue.
What we have here is a bean class generated by a JAX-RPC compliant tool other than WSDL2Java. Axis takes a "best effort" approach to doing an invocation with such beans; patching that to solve one problem will not help. I would advocate declaring as a WSIF limitation that only WSDL2Java generated beans will work 100% of the time, other beans might work but we make no claims. Then we work on rearchitecting WSIF to allow type mappings to be discovered and to populate Axis type maps dynamically prior to (de)serialization (changing Axis to allow such stuff if it isn't possible right now), i.e. option (2) on Ant's list.
Nirmal.
| "Anthony Elder" <[EMAIL PROTECTED]>
02/19/2003 01:28 PM
|
To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: Subject: RE: [wsif] generic type mapping [Re: bug 16485 [BeanDeserializer error when XML element starts with a capital letter]] |
Glen, I do agree with all you say.
The problem is today WSIF is broken. Yes if we can architect a new
mechanism for defining this metadata in the WSIF WSDL bindings, AND AXIS
comes up with a way to dynamically add this metadata at run time, then I
can change the WSIF AXIS provider to use this new stuff. How long for all
that to happen? And this doesn't really help for someone using WSIF as a
client to access a service where they don't have control over the WSDL.
Yes WSIF having a patched bean serializer isn't ideal. As you say the AXIS
bean serializer does work with most beans without the AXIS TypeDesc info
because the default name mappings are enough, but where the element name
starts with a capital letter these naming conventions don't work. The JAXB
spec points out this problem with the solution being to revise the schema,
not so user friendly from the point of view of seemlessly interoperating
with .Net which seem to often use capital letters.
This problem really is because of the way field names are determined using
Java introspection based on the names of the getter and setter methods -
this just doesn't work if the field starts with a capital letter. Which is
why this seems like a special case and I ask if perhaps it should be
tolerated automatically, without the user needing to provide any metadata?
...ant
Anthony Elder
[EMAIL PROTECTED]
Web Services Development
IBM UK Laboratories, Hursley Park
(+44) 01962 818320, x248320, MP208.
Glen Daniels <[EMAIL PROTECTED]> on 19/02/2003 17:50:39
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>,
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: [wsif] generic type mapping [Re: bug 16485
[BeanDeserializer error when XML element starts with a capital
letter]]
> Here's the deal. Java<->XML databinding REQUIRES metadata,
> that is all there is to it.
Let me clarify that a bit - it is certainly possible that the default
mapping (for instance, the default JAX-RPC mapping) just works, in which
case there is no need for EXPLICIT metadata, even though there is still
IMPLICIT metadata in the mapping rules. In other words, if the XML is
<name> and it maps to a field "name", you're fine without a TypeDesc. But
if the XML is <foo-bar> mapping to a field "fooBar", you'd better have it
so you can serialize correctly.
--G
Glen Daniels <[EMAIL PROTECTED]> on 19/02/2003 17:34:41
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>,
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: [wsif] generic type mapping [Re: bug 16485
[BeanDeserializer error when XML element starts with a capital
letter]]
ant:
Here's the deal. Java<->XML databinding REQUIRES metadata, that is all
there is to it. If you're auto-generating either side, then the metadata
will be there for whatever system (castor, axis, etc) you're generating
with. If you're using classes you whipped up with one system (or by hand)
and wanting to use them with another system, you will need to get the right
kind metadata in place somehow.
Earlier in the conversation, you said:
> 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.
That is, IMHO, a fallacy. Symbols not matching are simply symbols not
matching, whether it's "name"<->"Name" or "name"<->"foozle".
Patching the BeanSerializer is a cheesy hack which doesn't really solve the
problem at all, it just makes the assumption that all binding mismatches
will be because the first character is the wrong case.
I don't think you have to make WSIF depend on Axis (though as I've
mentioned in other forums, I frankly think that the projects should
eventually merge, since there's too much duplicated work on both sides),
however if you're expecting to use data classes with XML bindings in Axis,
you'll need to supply Axis with appropriate metadata.
If you guys are generating these classes with JAXB or WASP or whatever, I
guarantee you that they have some kind of metadata to handle the name
mapping. So the thing to do is to find out where that metadata lives, and
supply it to Axis in a way that we can consume. Trying to ignore it is,
IMHO, a big mistake.
(speaking of metadata, how do you guys handle class fields which map to
attributes and not elements? You need metadata for that too, right?)
I'm open to the idea of dynamically adding this stuff - so instead of a
generated class, you could do something like
"TypeDesc.registerTypeDescForClass(Class cls, TypeDesc typeDesc)". That
would let you guys write the TypeDesc however you wanted and then hand it
to us (you would only need to fill in FieldDescs for places where there is
an actual mismatch). This is basically "option 2" below.
Hope this makes sense,
--Glen
> -----Original Message-----
> From: Anthony Elder [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 19, 2003 12:12 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [wsif] generic type mapping [Re: bug 16485
> [BeanDeserializer error when XML element starts with a
> capital letter]]
>
>
>
> 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
> [EMAIL PROTECTED]
> Web Services Development
> IBM UK Laboratories, Hursley Park
> (+44) 01962 818320, x248320, MP208.
>
>
> Aleksander Slominski <[EMAIL PROTECTED]> on 19/02/2003 16:27:08
>
> Please respond to [EMAIL PROTECTED]
>
> To: [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED]
> 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
>
>
>
>
>
