You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by Chris Kelly <ab...@tolstoy.com> on 2002/12/02 01:48:42 UTC
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?
Re: passing interfaces instead of classes
Posted by Alex Dovlecel <do...@kbs.twi.tudelft.nl>.
> Right now, it will fail because [de-]serializers are found by exact type
> match only (or a default if one is defined, but this is typically
> useless). I did not take the time to change the [de-]serializer lookup,
> because I am not sure what the right way is to implement polymorphic
> return values.
yeah, it quite sucks. I would have done the patch myself some month ago (when
hit the wall myself) but had not too much experience with apache soap. I
don't have it not even now so... :o(
>
> One issue is, how will a client know what different types it can receive
> if the return value is polymorphic? In your example, a client who
> thinks the contract is A getA() may always expect to deserialize an A.
> Receiving a B would be an error: the client does not even know what a B
> is! This is a place where WSDL would be a big help.
But I don't know how should be of a big help? Just by noticing the user that
there are alot of classes to be mapped (like B class that extends A)? (not
too much experience on this too).
And then you should generate the classes by using a WSDL2Java tool or
something similar?
> You have raised the other major issue: should the service have to map
> all of the concrete types that may be returned?
This is usually the way I do... Is it wrong?
For example, I map all my class that could be serialized by soap. And usually
I have total control over the client, so I do the same thing there... adding
most of the mappings... (maibe even all of them) .
> I am thinking that to address the first issue, I should make return
> value polymorphism an option in the deployment descriptor, so that the
> service implementor will have to explicitly enable it for the service.
> It would then be up to the implementor to document the possible return
> types for client implementors.
Cool...
>
> For the second issue, I would walk the inheritance chain looking for a
> serializer, then check implemented interfaces for one. This really is
> not too big of a deal.
I suppose this is the way axis handles inheritance... could you tell me if I
am wrong with this one? BEcause right now I use axis (started one month ago)
and I don't want to find this issues right when I don't have the time to
solve them :o(
>
> Scott Nichol
Tx for clarifying some buggy things walking through my mind
dovle
Re: passing interfaces instead of classes
Posted by Alex Dovlecel <do...@kbs.twi.tudelft.nl>.
> Right now, it will fail because [de-]serializers are found by exact type
> match only (or a default if one is defined, but this is typically
> useless). I did not take the time to change the [de-]serializer lookup,
> because I am not sure what the right way is to implement polymorphic
> return values.
yeah, it quite sucks. I would have done the patch myself some month ago (when
hit the wall myself) but had not too much experience with apache soap. I
don't have it not even now so... :o(
>
> One issue is, how will a client know what different types it can receive
> if the return value is polymorphic? In your example, a client who
> thinks the contract is A getA() may always expect to deserialize an A.
> Receiving a B would be an error: the client does not even know what a B
> is! This is a place where WSDL would be a big help.
But I don't know how should be of a big help? Just by noticing the user that
there are alot of classes to be mapped (like B class that extends A)? (not
too much experience on this too).
And then you should generate the classes by using a WSDL2Java tool or
something similar?
> You have raised the other major issue: should the service have to map
> all of the concrete types that may be returned?
This is usually the way I do... Is it wrong?
For example, I map all my class that could be serialized by soap. And usually
I have total control over the client, so I do the same thing there... adding
most of the mappings... (maibe even all of them) .
> I am thinking that to address the first issue, I should make return
> value polymorphism an option in the deployment descriptor, so that the
> service implementor will have to explicitly enable it for the service.
> It would then be up to the implementor to document the possible return
> types for client implementors.
Cool...
>
> For the second issue, I would walk the inheritance chain looking for a
> serializer, then check implemented interfaces for one. This really is
> not too big of a deal.
I suppose this is the way axis handles inheritance... could you tell me if I
am wrong with this one? BEcause right now I use axis (started one month ago)
and I don't want to find this issues right when I don't have the time to
solve them :o(
>
> Scott Nichol
Tx for clarifying some buggy things walking through my mind
dovle
Re: passing interfaces instead of classes
Posted by Scott Nichol <sn...@scottnichol.com>.
FYI, I have now written the code I describe below. It does not break
any of my existing code in the case where polymorphism is *not*
specified. I have to come up with some tests of the polymorphism before
I commit the code.
Also, this lays the groundwork for polymorphic serialization in general
(i.e. on the client).
Scott Nichol
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Wednesday, December 04, 2002 10:28 AM
Subject: Re: passing interfaces instead of classes
> Right now, it will fail because [de-]serializers are found by exact
type
> match only (or a default if one is defined, but this is typically
> useless). I did not take the time to change the [de-]serializer
lookup,
> because I am not sure what the right way is to implement polymorphic
> return values.
>
> One issue is, how will a client know what different types it can
receive
> if the return value is polymorphic? In your example, a client who
> thinks the contract is A getA() may always expect to deserialize an A.
> Receiving a B would be an error: the client does not even know what a
B
> is! This is a place where WSDL would be a big help.
>
> You have raised the other major issue: should the service have to map
> all of the concrete types that may be returned?
>
> I am thinking that to address the first issue, I should make return
> value polymorphism an option in the deployment descriptor, so that the
> service implementor will have to explicitly enable it for the service.
> It would then be up to the implementor to document the possible return
> types for client implementors.
>
> For the second issue, I would walk the inheritance chain looking for a
> serializer, then check implemented interfaces for one. This really is
> not too big of a deal.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Alex Dovlecel" <do...@kbs.twi.tudelft.nl>
> To: <so...@xml.apache.org>
> Sent: Wednesday, December 04, 2002 9:42 AM
> Subject: Re: passing interfaces instead of classes
>
>
> > Have some questions about it (I have not read the changed code).
> >
> > If I have a method with the following signature:
> >
> > A getA ( ) ;
> >
> > and B extends A.
> >
> > I have mapped the A class into the SOAP engine, but the B class is
not
> mapped
> > (no QName and serializer associated).
> >
> > If the getA( ) will return a B, what SOAP will do ? Will fail
because
> could
> > not find (de)serializer for type B, or will try to find the closest
> mapped
> > type and use the serializer for that type? (in that case, will
> serialize the
> > B as an A object)
> >
> > pls answer me,
> > Tx
> > dovle
> >
> >
> > >
> > > I have just committed a change so that the return value of a
service
> > > method is serialized using its actual class rather than its
declared
> > > one, assuming the declared one is not a primitive type. This
> feature
> > > will be available in future nightly builds, which are accessed at
> > > http://cvs.apache.org/dist/soap/nightly/.
> > >
> > > Scott Nichol
> > >
> > > ----- Original Message -----
> > > From: "Scott Nichol" <sn...@scottnichol.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Monday, December 02, 2002 5:12 PM
> > > Subject: Re: passing interfaces instead of classes
> > >
> > > > 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" <ab...@tolstoy.com>
> > > > To: <so...@xml.apache.org>
> > > > 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" <ab...@tolstoy.com>
> > > > > >To: <so...@xml.apache.org>
> > > > > >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:
> > > > > >
> > > > > ><ma...@xml.apache.org>
> > > > > >
> > > > > >> For additional commands, e-mail:
> > > > > >
> > > > > ><ma...@xml.apache.org>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >--
> > > > > >To unsubscribe, e-mail:
> > > >
> > > > <ma...@xml.apache.org>
> > > >
> > > > > >For additional commands, e-mail:
> > > >
> > > > <ma...@xml.apache.org>
> > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > >
> > > > <ma...@xml.apache.org>
> > > >
> > > > > For additional commands, e-mail:
> > > >
> > > > <ma...@xml.apache.org>
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > >
> > > <ma...@xml.apache.org>
> > >
> > > > For additional commands, e-mail:
> > >
> > > <ma...@xml.apache.org>
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: passing interfaces instead of classes
Posted by Scott Nichol <sn...@scottnichol.com>.
FYI, I have now written the code I describe below. It does not break
any of my existing code in the case where polymorphism is *not*
specified. I have to come up with some tests of the polymorphism before
I commit the code.
Also, this lays the groundwork for polymorphic serialization in general
(i.e. on the client).
Scott Nichol
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Wednesday, December 04, 2002 10:28 AM
Subject: Re: passing interfaces instead of classes
> Right now, it will fail because [de-]serializers are found by exact
type
> match only (or a default if one is defined, but this is typically
> useless). I did not take the time to change the [de-]serializer
lookup,
> because I am not sure what the right way is to implement polymorphic
> return values.
>
> One issue is, how will a client know what different types it can
receive
> if the return value is polymorphic? In your example, a client who
> thinks the contract is A getA() may always expect to deserialize an A.
> Receiving a B would be an error: the client does not even know what a
B
> is! This is a place where WSDL would be a big help.
>
> You have raised the other major issue: should the service have to map
> all of the concrete types that may be returned?
>
> I am thinking that to address the first issue, I should make return
> value polymorphism an option in the deployment descriptor, so that the
> service implementor will have to explicitly enable it for the service.
> It would then be up to the implementor to document the possible return
> types for client implementors.
>
> For the second issue, I would walk the inheritance chain looking for a
> serializer, then check implemented interfaces for one. This really is
> not too big of a deal.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Alex Dovlecel" <do...@kbs.twi.tudelft.nl>
> To: <so...@xml.apache.org>
> Sent: Wednesday, December 04, 2002 9:42 AM
> Subject: Re: passing interfaces instead of classes
>
>
> > Have some questions about it (I have not read the changed code).
> >
> > If I have a method with the following signature:
> >
> > A getA ( ) ;
> >
> > and B extends A.
> >
> > I have mapped the A class into the SOAP engine, but the B class is
not
> mapped
> > (no QName and serializer associated).
> >
> > If the getA( ) will return a B, what SOAP will do ? Will fail
because
> could
> > not find (de)serializer for type B, or will try to find the closest
> mapped
> > type and use the serializer for that type? (in that case, will
> serialize the
> > B as an A object)
> >
> > pls answer me,
> > Tx
> > dovle
> >
> >
> > >
> > > I have just committed a change so that the return value of a
service
> > > method is serialized using its actual class rather than its
declared
> > > one, assuming the declared one is not a primitive type. This
> feature
> > > will be available in future nightly builds, which are accessed at
> > > http://cvs.apache.org/dist/soap/nightly/.
> > >
> > > Scott Nichol
> > >
> > > ----- Original Message -----
> > > From: "Scott Nichol" <sn...@scottnichol.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Monday, December 02, 2002 5:12 PM
> > > Subject: Re: passing interfaces instead of classes
> > >
> > > > 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" <ab...@tolstoy.com>
> > > > To: <so...@xml.apache.org>
> > > > 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" <ab...@tolstoy.com>
> > > > > >To: <so...@xml.apache.org>
> > > > > >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:
> > > > > >
> > > > > ><ma...@xml.apache.org>
> > > > > >
> > > > > >> For additional commands, e-mail:
> > > > > >
> > > > > ><ma...@xml.apache.org>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >--
> > > > > >To unsubscribe, e-mail:
> > > >
> > > > <ma...@xml.apache.org>
> > > >
> > > > > >For additional commands, e-mail:
> > > >
> > > > <ma...@xml.apache.org>
> > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > >
> > > > <ma...@xml.apache.org>
> > > >
> > > > > For additional commands, e-mail:
> > > >
> > > > <ma...@xml.apache.org>
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > >
> > > <ma...@xml.apache.org>
> > >
> > > > For additional commands, e-mail:
> > >
> > > <ma...@xml.apache.org>
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: passing interfaces instead of classes
Posted by Scott Nichol <sn...@scottnichol.com>.
Right now, it will fail because [de-]serializers are found by exact type
match only (or a default if one is defined, but this is typically
useless). I did not take the time to change the [de-]serializer lookup,
because I am not sure what the right way is to implement polymorphic
return values.
One issue is, how will a client know what different types it can receive
if the return value is polymorphic? In your example, a client who
thinks the contract is A getA() may always expect to deserialize an A.
Receiving a B would be an error: the client does not even know what a B
is! This is a place where WSDL would be a big help.
You have raised the other major issue: should the service have to map
all of the concrete types that may be returned?
I am thinking that to address the first issue, I should make return
value polymorphism an option in the deployment descriptor, so that the
service implementor will have to explicitly enable it for the service.
It would then be up to the implementor to document the possible return
types for client implementors.
For the second issue, I would walk the inheritance chain looking for a
serializer, then check implemented interfaces for one. This really is
not too big of a deal.
Scott Nichol
----- Original Message -----
From: "Alex Dovlecel" <do...@kbs.twi.tudelft.nl>
To: <so...@xml.apache.org>
Sent: Wednesday, December 04, 2002 9:42 AM
Subject: Re: passing interfaces instead of classes
> Have some questions about it (I have not read the changed code).
>
> If I have a method with the following signature:
>
> A getA ( ) ;
>
> and B extends A.
>
> I have mapped the A class into the SOAP engine, but the B class is not
mapped
> (no QName and serializer associated).
>
> If the getA( ) will return a B, what SOAP will do ? Will fail because
could
> not find (de)serializer for type B, or will try to find the closest
mapped
> type and use the serializer for that type? (in that case, will
serialize the
> B as an A object)
>
> pls answer me,
> Tx
> dovle
>
>
> >
> > I have just committed a change so that the return value of a service
> > method is serialized using its actual class rather than its declared
> > one, assuming the declared one is not a primitive type. This
feature
> > will be available in future nightly builds, which are accessed at
> > http://cvs.apache.org/dist/soap/nightly/.
> >
> > Scott Nichol
> >
> > ----- Original Message -----
> > From: "Scott Nichol" <sn...@scottnichol.com>
> > To: <so...@xml.apache.org>
> > Sent: Monday, December 02, 2002 5:12 PM
> > Subject: Re: passing interfaces instead of classes
> >
> > > 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" <ab...@tolstoy.com>
> > > To: <so...@xml.apache.org>
> > > 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" <ab...@tolstoy.com>
> > > > >To: <so...@xml.apache.org>
> > > > >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:
> > > > >
> > > > ><ma...@xml.apache.org>
> > > > >
> > > > >> For additional commands, e-mail:
> > > > >
> > > > ><ma...@xml.apache.org>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >--
> > > > >To unsubscribe, e-mail:
> > >
> > > <ma...@xml.apache.org>
> > >
> > > > >For additional commands, e-mail:
> > >
> > > <ma...@xml.apache.org>
> > >
> > > > --
> > > > To unsubscribe, e-mail:
> > >
> > > <ma...@xml.apache.org>
> > >
> > > > For additional commands, e-mail:
> > >
> > > <ma...@xml.apache.org>
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> >
> > <ma...@xml.apache.org>
> >
> > > For additional commands, e-mail:
> >
> > <ma...@xml.apache.org>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: passing interfaces instead of classes
Posted by Scott Nichol <sn...@scottnichol.com>.
Right now, it will fail because [de-]serializers are found by exact type
match only (or a default if one is defined, but this is typically
useless). I did not take the time to change the [de-]serializer lookup,
because I am not sure what the right way is to implement polymorphic
return values.
One issue is, how will a client know what different types it can receive
if the return value is polymorphic? In your example, a client who
thinks the contract is A getA() may always expect to deserialize an A.
Receiving a B would be an error: the client does not even know what a B
is! This is a place where WSDL would be a big help.
You have raised the other major issue: should the service have to map
all of the concrete types that may be returned?
I am thinking that to address the first issue, I should make return
value polymorphism an option in the deployment descriptor, so that the
service implementor will have to explicitly enable it for the service.
It would then be up to the implementor to document the possible return
types for client implementors.
For the second issue, I would walk the inheritance chain looking for a
serializer, then check implemented interfaces for one. This really is
not too big of a deal.
Scott Nichol
----- Original Message -----
From: "Alex Dovlecel" <do...@kbs.twi.tudelft.nl>
To: <so...@xml.apache.org>
Sent: Wednesday, December 04, 2002 9:42 AM
Subject: Re: passing interfaces instead of classes
> Have some questions about it (I have not read the changed code).
>
> If I have a method with the following signature:
>
> A getA ( ) ;
>
> and B extends A.
>
> I have mapped the A class into the SOAP engine, but the B class is not
mapped
> (no QName and serializer associated).
>
> If the getA( ) will return a B, what SOAP will do ? Will fail because
could
> not find (de)serializer for type B, or will try to find the closest
mapped
> type and use the serializer for that type? (in that case, will
serialize the
> B as an A object)
>
> pls answer me,
> Tx
> dovle
>
>
> >
> > I have just committed a change so that the return value of a service
> > method is serialized using its actual class rather than its declared
> > one, assuming the declared one is not a primitive type. This
feature
> > will be available in future nightly builds, which are accessed at
> > http://cvs.apache.org/dist/soap/nightly/.
> >
> > Scott Nichol
> >
> > ----- Original Message -----
> > From: "Scott Nichol" <sn...@scottnichol.com>
> > To: <so...@xml.apache.org>
> > Sent: Monday, December 02, 2002 5:12 PM
> > Subject: Re: passing interfaces instead of classes
> >
> > > 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" <ab...@tolstoy.com>
> > > To: <so...@xml.apache.org>
> > > 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" <ab...@tolstoy.com>
> > > > >To: <so...@xml.apache.org>
> > > > >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:
> > > > >
> > > > ><ma...@xml.apache.org>
> > > > >
> > > > >> For additional commands, e-mail:
> > > > >
> > > > ><ma...@xml.apache.org>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >--
> > > > >To unsubscribe, e-mail:
> > >
> > > <ma...@xml.apache.org>
> > >
> > > > >For additional commands, e-mail:
> > >
> > > <ma...@xml.apache.org>
> > >
> > > > --
> > > > To unsubscribe, e-mail:
> > >
> > > <ma...@xml.apache.org>
> > >
> > > > For additional commands, e-mail:
> > >
> > > <ma...@xml.apache.org>
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> >
> > <ma...@xml.apache.org>
> >
> > > For additional commands, e-mail:
> >
> > <ma...@xml.apache.org>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: passing interfaces instead of classes
Posted by Alex Dovlecel <do...@kbs.twi.tudelft.nl>.
Have some questions about it (I have not read the changed code).
If I have a method with the following signature:
A getA ( ) ;
and B extends A.
I have mapped the A class into the SOAP engine, but the B class is not mapped
(no QName and serializer associated).
If the getA( ) will return a B, what SOAP will do ? Will fail because could
not find (de)serializer for type B, or will try to find the closest mapped
type and use the serializer for that type? (in that case, will serialize the
B as an A object)
pls answer me,
Tx
dovle
>
> I have just committed a change so that the return value of a service
> method is serialized using its actual class rather than its declared
> one, assuming the declared one is not a primitive type. This feature
> will be available in future nightly builds, which are accessed at
> http://cvs.apache.org/dist/soap/nightly/.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Scott Nichol" <sn...@scottnichol.com>
> To: <so...@xml.apache.org>
> Sent: Monday, December 02, 2002 5:12 PM
> Subject: Re: passing interfaces instead of classes
>
> > 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" <ab...@tolstoy.com>
> > To: <so...@xml.apache.org>
> > 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" <ab...@tolstoy.com>
> > > >To: <so...@xml.apache.org>
> > > >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:
> > > >
> > > ><ma...@xml.apache.org>
> > > >
> > > >> For additional commands, e-mail:
> > > >
> > > ><ma...@xml.apache.org>
> > > >
> > > >
> > > >
> > > >
> > > >--
> > > >To unsubscribe, e-mail:
> >
> > <ma...@xml.apache.org>
> >
> > > >For additional commands, e-mail:
> >
> > <ma...@xml.apache.org>
> >
> > > --
> > > To unsubscribe, e-mail:
> >
> > <ma...@xml.apache.org>
> >
> > > For additional commands, e-mail:
> >
> > <ma...@xml.apache.org>
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@xml.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@xml.apache.org>
Re: passing interfaces instead of classes
Posted by Alex Dovlecel <do...@kbs.twi.tudelft.nl>.
Have some questions about it (I have not read the changed code).
If I have a method with the following signature:
A getA ( ) ;
and B extends A.
I have mapped the A class into the SOAP engine, but the B class is not mapped
(no QName and serializer associated).
If the getA( ) will return a B, what SOAP will do ? Will fail because could
not find (de)serializer for type B, or will try to find the closest mapped
type and use the serializer for that type? (in that case, will serialize the
B as an A object)
pls answer me,
Tx
dovle
>
> I have just committed a change so that the return value of a service
> method is serialized using its actual class rather than its declared
> one, assuming the declared one is not a primitive type. This feature
> will be available in future nightly builds, which are accessed at
> http://cvs.apache.org/dist/soap/nightly/.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Scott Nichol" <sn...@scottnichol.com>
> To: <so...@xml.apache.org>
> Sent: Monday, December 02, 2002 5:12 PM
> Subject: Re: passing interfaces instead of classes
>
> > 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" <ab...@tolstoy.com>
> > To: <so...@xml.apache.org>
> > 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" <ab...@tolstoy.com>
> > > >To: <so...@xml.apache.org>
> > > >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:
> > > >
> > > ><ma...@xml.apache.org>
> > > >
> > > >> For additional commands, e-mail:
> > > >
> > > ><ma...@xml.apache.org>
> > > >
> > > >
> > > >
> > > >
> > > >--
> > > >To unsubscribe, e-mail:
> >
> > <ma...@xml.apache.org>
> >
> > > >For additional commands, e-mail:
> >
> > <ma...@xml.apache.org>
> >
> > > --
> > > To unsubscribe, e-mail:
> >
> > <ma...@xml.apache.org>
> >
> > > For additional commands, e-mail:
> >
> > <ma...@xml.apache.org>
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@xml.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@xml.apache.org>
Re: passing interfaces instead of classes
Posted by Scott Nichol <sn...@scottnichol.com>.
Chris,
I have just committed a change so that the return value of a service
method is serialized using its actual class rather than its declared
one, assuming the declared one is not a primitive type. This feature
will be available in future nightly builds, which are accessed at
http://cvs.apache.org/dist/soap/nightly/.
Scott Nichol
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Monday, December 02, 2002 5:12 PM
Subject: Re: passing interfaces instead of classes
> 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" <ab...@tolstoy.com>
> To: <so...@xml.apache.org>
> 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" <ab...@tolstoy.com>
> > >To: <so...@xml.apache.org>
> > >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:
> > ><ma...@xml.apache.org>
> > >> For additional commands, e-mail:
> > ><ma...@xml.apache.org>
> > >>
> > >>
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > >For additional commands, e-mail:
> <ma...@xml.apache.org>
> > >
> > >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: passing interfaces instead of classes
Posted by Alex Dovlecel <do...@kbs.twi.tudelft.nl>.
On Monday 02 December 2002 23:12, you wrote:
> 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.
I am shure about it. We had similar problems, but not with an interface but a
class.
For example if you have class A and B (B extends A), and the method is
getA(): A.
If you return a B, the B will be serialized as A !!! Wich means loosing some
fields !!! There is a small patch I have received from someone on the list.
In fact the holl problem deals with polimorphism and somehow apache soap is
not so good at this.
dovle
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Chris Kelly" <ab...@tolstoy.com>
> To: <so...@xml.apache.org>
> 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" <ab...@tolstoy.com>
> > >To: <so...@xml.apache.org>
> > >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:
> > >
> > ><ma...@xml.apache.org>
> > >
> > >> For additional commands, e-mail:
> > >
> > ><ma...@xml.apache.org>
> > >
> > >
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
>
> <ma...@xml.apache.org>
>
> > >For additional commands, e-mail:
>
> <ma...@xml.apache.org>
>
> > --
> > To unsubscribe, e-mail:
>
> <ma...@xml.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@xml.apache.org>
Re: passing interfaces instead of classes
Posted by Alex Dovlecel <do...@kbs.twi.tudelft.nl>.
On Monday 02 December 2002 23:12, you wrote:
> 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.
I am shure about it. We had similar problems, but not with an interface but a
class.
For example if you have class A and B (B extends A), and the method is
getA(): A.
If you return a B, the B will be serialized as A !!! Wich means loosing some
fields !!! There is a small patch I have received from someone on the list.
In fact the holl problem deals with polimorphism and somehow apache soap is
not so good at this.
dovle
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Chris Kelly" <ab...@tolstoy.com>
> To: <so...@xml.apache.org>
> 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" <ab...@tolstoy.com>
> > >To: <so...@xml.apache.org>
> > >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:
> > >
> > ><ma...@xml.apache.org>
> > >
> > >> For additional commands, e-mail:
> > >
> > ><ma...@xml.apache.org>
> > >
> > >
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
>
> <ma...@xml.apache.org>
>
> > >For additional commands, e-mail:
>
> <ma...@xml.apache.org>
>
> > --
> > To unsubscribe, e-mail:
>
> <ma...@xml.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@xml.apache.org>
Re: passing interfaces instead of classes
Posted by Scott Nichol <sn...@scottnichol.com>.
Chris,
I have just committed a change so that the return value of a service
method is serialized using its actual class rather than its declared
one, assuming the declared one is not a primitive type. This feature
will be available in future nightly builds, which are accessed at
http://cvs.apache.org/dist/soap/nightly/.
Scott Nichol
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Monday, December 02, 2002 5:12 PM
Subject: Re: passing interfaces instead of classes
> 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" <ab...@tolstoy.com>
> To: <so...@xml.apache.org>
> 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" <ab...@tolstoy.com>
> > >To: <so...@xml.apache.org>
> > >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:
> > ><ma...@xml.apache.org>
> > >> For additional commands, e-mail:
> > ><ma...@xml.apache.org>
> > >>
> > >>
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > >For additional commands, e-mail:
> <ma...@xml.apache.org>
> > >
> > >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: passing interfaces instead of classes
Posted by Scott Nichol <sn...@scottnichol.com>.
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" <ab...@tolstoy.com>
To: <so...@xml.apache.org>
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" <ab...@tolstoy.com>
> >To: <so...@xml.apache.org>
> >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:
> ><ma...@xml.apache.org>
> >> For additional commands, e-mail:
> ><ma...@xml.apache.org>
> >>
> >>
> >
> >
> >--
> >To unsubscribe, e-mail:
<ma...@xml.apache.org>
> >For additional commands, e-mail:
<ma...@xml.apache.org>
> >
> >
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: passing interfaces instead of classes
Posted by Scott Nichol <sn...@scottnichol.com>.
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" <ab...@tolstoy.com>
To: <so...@xml.apache.org>
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" <ab...@tolstoy.com>
> >To: <so...@xml.apache.org>
> >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:
> ><ma...@xml.apache.org>
> >> For additional commands, e-mail:
> ><ma...@xml.apache.org>
> >>
> >>
> >
> >
> >--
> >To unsubscribe, e-mail:
<ma...@xml.apache.org>
> >For additional commands, e-mail:
<ma...@xml.apache.org>
> >
> >
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: passing interfaces instead of classes
Posted by Chris Kelly <ab...@tolstoy.com>.
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" <ab...@tolstoy.com>
>To: <so...@xml.apache.org>
>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:
><ma...@xml.apache.org>
>> For additional commands, e-mail:
><ma...@xml.apache.org>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@xml.apache.org>
>For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: passing interfaces instead of classes
Posted by Chris Kelly <ab...@tolstoy.com>.
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" <ab...@tolstoy.com>
>To: <so...@xml.apache.org>
>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:
><ma...@xml.apache.org>
>> For additional commands, e-mail:
><ma...@xml.apache.org>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@xml.apache.org>
>For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: passing interfaces instead of classes
Posted by Scott Nichol <sn...@scottnichol.com>.
Chris,
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.
Scott Nichol
----- Original Message -----
From: "Chris Kelly" <ab...@tolstoy.com>
To: <so...@xml.apache.org>
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:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: passing interfaces instead of classes
Posted by Scott Nichol <sn...@scottnichol.com>.
Chris,
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.
Scott Nichol
----- Original Message -----
From: "Chris Kelly" <ab...@tolstoy.com>
To: <so...@xml.apache.org>
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:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>