Rich, >So everything is fine if all services send arrays over with type ="soapenc:Array". >But if a service sends over a more specific type="ns:ArrayOfFoo", then the client >runtime needs to know that they are arrays and not beans.
Ok, then anyway with what I wanted to fix we'll support the best case. The other case results in a situation that can only be resolved with typeMappings, then so be it. The best case in the meantime will work just fine without typeMappings. -- Igor Sedukhin .. ([EMAIL PROTECTED]) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] Sent: Friday, February 08, 2002 4:54 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Default bean mappings >>If the xml is set over the wire with type="soapenc:Array" then >>the array deserializer will be called. But the xml could be sent >>across the wire with type="ns:ArrayOfFoo", in which case, the runtime needs to call the array >>deserializer instead of the bean deserializer. >So what would arrayItemType be in the later case when such request gets >to Axis? >context.getTypeMapping().getClassForQName(arrayItemType); >This is the code in the ArrayDeserializer... >How is type="ns:ArrayOfFoo" case handled right now? Do I have to setup >a specific the beanMapping for that. An array could be sent across with type="ns:ArrayOfFoo". So the only way a runtime could know how to deserialize such a thing is to have a <typeMapping> registered that indicates to use the ArrayDeserializer. See the samples/echo/deploy.wsdd for an example. In some cases, (I think kSoap in the interop tests) the soapenc:arrayType attribute is missing. So the ArrayDeserializer uses the information in the specific type= to ascertain the item type. (Note this is a recent improvement). So everything is fine if all services send arrays over with type ="soapenc:Array". But if a service sends over a more specific type="ns:ArrayOfFoo", then the client runtime needs to know that they are arrays and not beans. Rich Scheuerle XML & Web Services Development 512-838-5115 (IBM TL 678-5115) "Sedukhin, Igor" <Igor.Sedukhin@ca To: [EMAIL PROTECTED] .com> cc: Subject: RE: Default bean mappings 02/08/2002 02:58 PM Please respond to axis-dev Rich, >If the xml is set over the wire with type="soapenc:Array" then >the array deserializer will be called. But the xml could be sent >across the wire with type="ns:ArrayOfFoo", in which case, the runtime needs to call the array >deserializer instead of the bean deserializer. So what would arrayItemType be in the later case when such request gets to Axis? context.getTypeMapping().getClassForQName(arrayItemType); This is the code in the ArrayDeserializer... How is type="ns:ArrayOfFoo" case handled right now? Do I have to setup a specific the beanMapping for that. Also where is this ambiguity coming from? SOAP-ENC? Thanks, -- Igor Sedukhin .. ([EMAIL PROTECTED]) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] Sent: Friday, February 08, 2002 3:47 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Default bean mappings >>You also need to worry about array mappings. >Not really. In WSDL they'll be generated properly anyways, and when it gets down to SOAP pipeline it'll >resolve it, for example, to ArrayDeserializer, which in turn would >componentType = >context.getTypeMapping().getClassForQName(arrayItemType); >And that'll make it to the DefaultTypeMappingImpl and it's all good. I >don't think we'll have problems with arrays. Yes and no. If the xml is set over the wire with type="soapenc:Array" then the array deserializer will be called. But the xml could be sent across the wire with type="ns:ArrayOfFoo", in which case, the runtime needs to call the array deserializer instead of the bean deserializer. Rich Scheuerle XML & Web Services Development 512-838-5115 (IBM TL 678-5115) "Sedukhin, Igor" <Igor.Sedukhin@ca To: [EMAIL PROTECTED] .com> cc: Subject: RE: Default bean mappings 02/08/2002 10:46 AM Please respond to axis-dev Rich, >You also need to worry about array mappings. Not really. In WSDL they'll be generated properly anyways, and when it gets down to SOAP pipeline it'll resolve it, for example, to ArrayDeserializer, which in turn would componentType = context.getTypeMapping ().getClassForQName(arrayItemType); And that'll make it to the DefaultTypeMappingImpl and it's all good. I don't think we'll have problems with arrays. >If the JSR's came up with a namespace <-> package mapping I would be inclined to do agree with you. It's really the WSAWG or WSDWG or WS-I task to define how to map OO model hierarchy expressed in the XML Schema in a WSDL. JSR would just interpret it for Java then. >I would much prefer something like the following: <namespaceMapping It is indeed a better alternative to beanMappings, but I wanted to have something really simple. For a simple Java classes being published I don't think the namespace mangling is really needed unless some ambiguity resolution or a prototype WSDL compliance is needed. The Emitter is already doing a good job by generating WSDL without any mappings present. -- Igor Sedukhin .. ([EMAIL PROTECTED]) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] Sent: Friday, February 08, 2002 11:03 AM To: [EMAIL PROTECTED] Subject: Re: Default bean mappings If the JSR's came up with a namespace <-> package mapping I would be inclined to do agree with you. You also need to worry about array mappings. What if the QName is QName (" http://model.address.myapp";, "ArrayOfAddress") ? in such cases it should figure out to map to model.address.myApp.Address []... I agree that I don't like the type mapping registration. I would much prefer something like the following: <namespaceMapping namespace="http:foo.com" package="my.foo.package" arrayQNamePrefix="ArrayOf" <!-- the following are optional attributes --> beanSerializerFactory = ... beanDeserializerFactory = ... arraySerializerFactory = ... arrayDeserializerFactory = ... /> So the above would indicate to map all qnames in the indicated namespace to classes of the indicated package. The arrayQNamePrefix setting indicates how to recognize array qnames. Rich Scheuerle XML & Web Services Development 512-838-5115 (IBM TL 678-5115) "Sedukhin, Igor" <Igor.Sedukhin@ca To: [EMAIL PROTECTED] .com> cc: Subject: Default bean mappings 02/08/2002 07:55 AM Please respond to axis-dev This bugs me for a while already. May be there is a reason it is happening this way, but please refresh me on it. Here is what: By default Emitter generates type namespaces and type declarations like this: <wsdl:definitions ... xmlns:tns1="http://model.address.myapp"; ...> <types> <schema targetNamespace="http://model.address.myapp"; ...> <complexType name ="Address"> ... This is basically for a class myapp.address.model.Address. So, why is it that I had to explicitly declare beanMappings during the deployment for proper ser/deser to be selected by the RPCHandler? It seems it is very easy to try and reconstruct a class name from the default assumption about the namespace format and then check if the class is loadable, then only apply explicit beanMappings. I'd really like to get it this simple. It is possible to change DefaultTypeMappingImpl to implement getTypeQName, getSerializer and getDesearializer to take care of it as explained above. Does anyone have objection or comments on this? -- Igor Sedukhin .. ([EMAIL PROTECTED]) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
