Return-Path: Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 9722 invoked by uid 500); 20 Feb 2003 12:35:45 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 9655 invoked from network); 20 Feb 2003 12:35:44 -0000 Importance: Normal Sensitivity: Subject: RE: [wsif] generic type mapping [Re: bug 16485 [BeanDeserializer error when XML element starts with a capital letter]] To: wsif-dev@ws.apache.org, axis-dev@ws.apache.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Anthony Elder" Date: Thu, 20 Feb 2003 12:35:32 +0000 X-MIMETrack: Serialize by Router on D06ML038/06/M/IBM(Release 5.0.9a |January 7, 2002) at 20/02/2003 12:35:36 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I think there may be some misunderstanding about this problem. If you have a Java bean with a field String xyz; // <-- starts with lowercase then Java conventions say there will be methods getXyz() and setXyz(). If you change the field name to be: String Xyz; // <-- starts with uppercase then Java conventions say there will be methods getXyz() and setXyz(). = Note the methods have identical names in both examples. The BeanSerializer uses the names of the methods to find what an XML element will map to. setXyz() is assumed to mean that there is a field named xyz, which maps to an element named xyz. But this assumption is w= rong in the second example, and if there is an element named Xyz there is *n= o way* in Java to differentiate the getter and setter methods. What this means is that currently it is *impossible* to use a simple be= an without TypeDesc info with a schema where an element name starts with a= capital letter. There wont be a new case tomorrow where we need a new patch to understa= nd some other character as this is the one single only very specific situa= tion where it doesn't work. Lets wait and see what Glen thinks about the new patch, to me it seems = by far the cleanest solution. ...ant Anthony Elder ant.elder@uk.ibm.com Web Services Development IBM UK Laboratories, Hursley Park (+44) 01962 818320, x248320, MP208. Nirmal Mukhi/Watson/IBM@IBMUS on 20/02/2003 11:49:58 Please respond to wsif-dev@ws.apache.org To: axis-dev@ws.apache.org, wsif-dev@ws.apache.org cc: Subject: RE: [wsif] generic type mapping [Re: bug 16485 [BeanDeserializer error when XML element starts with a capi= tal letter]] Hi, Glen's change to the TypeDesc class in Axis yesterday makes it possible= to register type descs for bean classes. What we need to do in WSIF is par= se the WSDL schema and map to the bean class and bean serializer (which we= already do), but at the same time create TypeDesc information for that = bean class (which we don't do right now). I understand that option (1) will *completely* take care of this proble= m. IMHO that leads us in the wrong direction. If we find that field names beginning with "_" cause a problem tomorrow, we will need another patch= to the bean serializer, which is why I don't advocate taking that approach= . Thanks, Nirmal. = =20 "Anthony Elder" = =20 wsif-dev@ws.apache.org, = =20 axis-dev@ws.apache.org = =20 02/20/2003 06:33 =A0 =A0 =A0 =A0 cc: = =20 AM =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0= =A0RE: [wsif] =20 Please respond to generic type mapping [Re: bug 16485= =20 axis-dev [BeanDeserializer =A0 =A0 =A0 =A0 e= rror when =20 XML element starts with a capital = =20 letter]] = =20 = =20 Pushing this case toleration some more how about this patch to the BeanSerializer then: Index: BeanDeserializer.java =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/cvspublic/xml-axis/java/src/org/apache/axis/encoding/ser/BeanDese= rializer.java,v retrieving revision 1.55 diff -u -r1.55 BeanDeserializer.java --- BeanDeserializer.java =A0 =A0 24 Sep 2002 23:27:35 -0000 =A0 =A01.5= 5 +++ BeanDeserializer.java =A0 =A0 20 Feb 2003 11:30:22 -0000 @@ -213,7 +213,11 @@ =A0 =A0 =A0 =A0 if (propDesc =3D=3D null) { =A0 =A0 =A0 =A0 =A0 =A0 // look for a field by this name. - =A0 =A0 =A0 =A0 =A0 =A0propDesc =3D (BeanPropertyDescriptor) propertyMap.get(localName); + =A0 =A0 =A0 =A0 =A0 =A0StringBuffer sb =3D new StringBuffer(localName= ); + =A0 =A0 =A0 =A0 =A0 =A0if (sb.length() > 0 && Character.isUpperCase(s= b.charAt(0))) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sb.setCharAt(0,Character.toLowerCase(s= b.charAt(0))); + =A0 =A0 =A0 =A0 =A0 =A0} + =A0 =A0 =A0 =A0 =A0 =A0propDesc =3D (BeanPropertyDescriptor) propertyMap.get(sb.toString()); =A0 =A0 =A0 =A0 } =A0 =A0 =A0 =A0 // try and see if this is an xsd:any namespace=3D"##any= " element before The point is if we've got here in the BeanSerializer and propDesc is nu= ll, then if the localName starts with an uppercase character the propertyMa= p will *never* have a match, so there's no point checking really. Whats m= ore if localName does start with a capital letter and propDesc is null we *know* there is no way a Java bean can be made to work as the field wil= l always be incorrectly assumed to start with a lower case character, so = this propertyMap lookup might as well make the same assumption. =A0 =A0 =A0 ...ant Anthony Elder ant.elder@uk.ibm.com Web Services Development IBM UK Laboratories, =A0Hursley Park (+44) 01962 818320, x248320, MP208. Anthony Elder/UK/IBM@IBMGB on 20/02/2003 08:54:10 Please respond to wsif-dev@ws.apache.org To: =A0 =A0wsif-dev@ws.apache.org, axis-dev@ws.apache.org cc: Subject: =A0 =A0RE: [wsif] generic type mapping [Re: bug 16485 =A0 =A0 =A0 [BeanDeserializer =A0 =A0 =A0error when XML element starts = with a capital =A0 =A0 =A0 letter]] The problem with option 2 is that its WSDL driven, but the WSIF client = may not have control over the WSDL, so WSIF still wont work with all that .= Net WSDL with the capital letters. So I think added to the original list of options should be: 4 - design a WSIF specific way to add the required metadata info to the= bean class and get the WSIF AXIS provider to somehow get that from the = bean and tell the AXIS BeanDeserializer about it. For this metadata perhaps we could create new WSIF classes called TypeD= esc and Field and a WSIF schema tool that creates beans from a schema which= include a static TypeDesc field initialised with the required metadata.= AXIS has already done that so we could just nick the existing AXIS clas= ses and change axis to wsif in their package name. ;) Option 1 is starting to look likely. I'd dispute the claim that "patching that to solve one problem will not= help" - yes it will help, tolerating variations in the case of the 1st character fixes this particular problem completely. =A0 =A0 =A0 ...ant Anthony Elder ant.elder@uk.ibm.com Web Services Development IBM UK Laboratories, =A0Hursley Park (+44) 01962 818320, x248320, MP208. Nirmal Mukhi/Watson/IBM@IBMUS on 19/02/2003 20:23:22 Please respond to axis-dev@ws.apache.org To: =A0 =A0axis-dev@ws.apache.org cc: =A0 =A0wsif-dev@ws.apache.org Subject: =A0 =A0RE: [wsif] generic type mapping [Re: bug 16485 =A0 =A0 =A0 [BeanDeserializer =A0 =A0 =A0error when XML element starts = with a capital =A0 =A0 =A0 letter]] 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 proble= m 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 WSDL2Ja= va 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 mappi= ngs to be discovered and to populate Axis type maps dynamically prior to (de)serialization (changing Axis to allow such stuff if it isn't possib= le right now), i.e. option (2) on Ant's list. Nirmal. =A0 =A0 =A0 "Anthony Elder" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wsif-d= ev@ws.apache.org, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= axis-dev@ws.apache.org =A0 =A0 =A0 02/19/2003 01:28 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cc= : =A0 =A0 =A0 PM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0RE: [wsif] =A0 =A0 =A0 Please respond to =A0 =A0 =A0 =A0 =A0 =A0generic type mappi= ng [Re: bug 16485 =A0 =A0 =A0 axis-dev =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [BeanDeser= ializer =A0 =A0 =A0 =A0 error when =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= XML element starts with a capital =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 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 AXI= S comes up with a way to dynamically add this metadata at run time, then can change the WSIF AXIS provider to use this new stuff. How long for a= ll that to happen? And this doesn't really help for someone using WSIF as 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 A= XIS bean serializer does work with most beans without the AXIS TypeDesc inf= o because the default name mappings are enough, but where the element nam= e starts with a capital letter these naming conventions don't work. The J= AXB spec points out this problem with the solution being to revise the sche= ma, not so user friendly from the point of view of seemlessly interoperatin= g with .Net which seem to often use capital letters. This problem really is because of the way field names are determined us= ing 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 metada= ta? =A0 =A0 =A0...ant Anthony Elder ant.elder@uk.ibm.com Web Services Development IBM UK Laboratories, =A0Hursley Park (+44) 01962 818320, x248320, MP208. Glen Daniels on 19/02/2003 17:50:39 Please respond to wsif-dev@ws.apache.org To: =A0 =A0"'axis-dev@ws.apache.org'" , =A0 =A0 =A0"'wsif-dev@ws.apache.org'" cc: Subject: =A0 =A0RE: [wsif] generic type mapping [Re: bug 16485 =A0 =A0 =A0[BeanDeserializer =A0 =A0 =A0 error when XML element starts = with a capital =A0 =A0 =A0letter]] > Here's the deal. =A0Java<->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 whic= h case there is no need for EXPLICIT metadata, even though there is still= IMPLICIT metadata in the mapping rules. =A0In other words, if the XML i= s and it maps to a field "name", you're fine without a TypeDesc. =A0= But if the XML is mapping to a field "fooBar", you'd better have = it so you can serialize correctly. --G Glen Daniels on 19/02/2003 17:34:41 Please respond to axis-dev@ws.apache.org To: =A0 =A0"'axis-dev@ws.apache.org'" , =A0 =A0 =A0"'wsif-dev@ws.apache.org'" cc: Subject: =A0 =A0RE: [wsif] generic type mapping [Re: bug 16485 =A0 =A0 =A0[BeanDeserializer =A0 =A0 =A0error when XML element starts w= ith a capital =A0 =A0 =A0letter]] ant: Here's the deal. =A0Java<->XML databinding REQUIRES metadata, that is a= ll there is to it. =A0If you're auto-generating either side, then the meta= data will be there for whatever system (castor, axis, etc) you're generating= with. =A0If 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 r= ight 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 =A0think 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. =A0Symbols not matching are simply symbols no= t 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 mismatche= s 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 Ax= is, you'll need to supply Axis with appropriate metadata. If you guys are generating these classes with JAXB or WASP or whatever,= guarantee you that they have some kind of metadata to handle the name mapping. =A0So the thing to do is to find out where that metadata lives= , and supply it to Axis in a way that we can consume. =A0Trying 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? =A0You 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)". =A0T= hat 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). =A0This is basically "option 2" below. Hope this makes sense, --Glen > -----Original Message----- > From: Anthony Elder [mailto:ant.elder@uk.ibm.com] > Sent: Wednesday, February 19, 2003 12:12 PM > To: wsif-dev@ws.apache.org; axis-dev@ws.apache.org > 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 provide= r > 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 bea= n > serializer which ignores the case of the 1st character of an > element name. > > =A0 =A0 =A0 =A0...ant > > Anthony Elder > ant.elder@uk.ibm.com > Web Services Development > IBM UK Laboratories, =A0Hursley Park > (+44) 01962 818320, x248320, MP208. > > > Aleksander Slominski on 19/02/2003 16:27:08 > > Please respond to axis-dev@ws.apache.org > > To: =A0 =A0wsif-dev@ws.apache.org > cc: =A0 =A0axis-dev@ws.apache.org > Subject: =A0 =A0Re: [wsif] generic type mapping [Re: bug 16485 > =A0 =A0 =A0 =A0[BeanDeserializer error when XML element starts with a= capital > =A0 =A0 =A0 =A0letter]] > > > > 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 =A0this makes W= SIF > >dependant on AXIS being used to generate the beans and thus > the client > code > >dependant upon the chosen binding, =A0and 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 > >completely different name than the Java class field I =A0think > it would be > >fine that it didn't work, but when just the case of the 1st characte= r > >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 > > > > > =