> 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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
