Without looking at the code, my guess would be that Apache SOAP
serializes the return value based on the declared type of the function,
not the actual type returned. I will have to look at this later.
Scott Nichol
----- Original Message -----
From: "Chris Kelly" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 02, 2002 5:26 PM
Subject: Re: passing interfaces instead of classes
> The problem I had is that my service actually looks like this:
>
> class SoapService {
> public IData doSomething( IData data ) {...}
> }
>
> When I tried to send a ComplexData or SimpleData concrete class back,
it
> didn't work. Are you saying that was just a config or similar problem?
> Currently, I use a return type mapping when one of the service methods
> returns an array. Do I need to set up a return type mapping, as shown
in
> the following code, or will the return be handled automatically and I
just
> had something set wrong?
>
> SOAPMappingRegistry smr;
> ...
> smr.mapTypes(
> Constants.NS_URI_SOAP_ENC,
> new QName( uri, "return" ),
> null,
> ???, ??? );
> ...
> call.setSOAPMappingRegistry( smr );
>
>
>
> At 09:09 AM 12/2/02 -0500, Scott Nichol wrote:
> >It is up to you when you define your mappings and/or write your
> >serializers whether the classes implementing interfaces will be
> >serialized with just information for the interface or for the actual
> >class. I personally prefer to have separate mappings for each
concrete
> >class. I don't like to have one serializer for an interface that
> >internally actually knows how to serialize each class that implements
> >the interface. Big switch statements or multiple if/else branches
don't
> >feel right to me in the O-O world.
> >
> >Anyway, in your case this means I would write serializers (and
> >deserializers) for SimpleData and ComplexData, then map each type to
the
> >corresponding [de-]serializer. The server will correctly resolve
these
> >types as parameters to the doSomething method.
> >
> >----- Original Message -----
> >From: "Chris Kelly" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Sunday, December 01, 2002 7:48 PM
> >Subject: passing interfaces instead of classes
> >
> >
> >> Consider:
> >>
> >> interface IData {
> >> int getValue();
> >> }
> >>
> >> class SimpleData implements IData {
> >> int value;
> >> public SimpleData( int v ) { value = v; }
> >> public int getValue() { return value; }
> >> }
> >>
> >> class ComplexData implements IData {
> >> float value, multiplier;
> >> public SimpleData( float v, float m; ) {
> >> value = v;
> >> multiplier = m;
> >> }
> >> public int getValue() {
> >> return (int) ( multiplier * value );
> >> }
> >> }
> >>
> >> Then, consider a service that accepts an IData object:
> >>
> >> class SoapService {
> >> public doSomething( IData data ) {...}
> >> }
> >>
> >> If I pass an IData object in a bean-like fashion, only the 'value'
> >will be
> >> sent in the XML, not the 'multiplier' if the IData object I'm
sending
> >is a
> >> ComplexData object.
> >>
> >> If I change SoapService.doSomething to accept either a SimpleData
or a
> >> ComplexData, then the other class can't be sent.
> >>
> >> So, am I missing something, or is it difficult to represent passed
> >objects
> >> as interfaces? Must they be represented as classes?
> >>
> >> One way around this would be to pass IData objects as the name in
the
> >XML,
> >> and include the name of the implementing class in the XML as well.
An
> >IData
> >> de/serializer would then determine the implementing class, and call
a
> >> de/serializer specific to that implementing class. Is there an
> >automatic
> >> way to do this?
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> >> For additional commands, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> >>
> >>
> >
> >
> >--
> >To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
> >
> >
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
