axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sedukhin, Igor" <Igor.Seduk...@ca.com>
Subject RE: Default bean mappings
Date Fri, 08 Feb 2002 22:40:56 GMT
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 .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



-----Original Message-----
From: R J Scheuerle Jr [mailto:scheu@us.ibm.com] 
Sent: Friday, February 08, 2002 4:54 PM
To: axis-dev@xml.apache.org
Cc: axis-dev@xml.apache.org
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:
axis-dev@xml.apache.org                                                  
                      .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 .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



-----Original Message-----
From: R J Scheuerle Jr [mailto:scheu@us.ibm.com]
Sent: Friday, February 08, 2002 3:47 PM
To: axis-dev@xml.apache.org
Cc: axis-dev@xml.apache.org
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:
axis-dev@xml.apache.org
                      .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 .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



-----Original Message-----
From: R J Scheuerle Jr [mailto:scheu@us.ibm.com]
Sent: Friday, February 08, 2002 11:03 AM
To: axis-dev@xml.apache.org
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:
axis-dev@xml.apache.org
                      .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 .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788













Mime
View raw message