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 Dieter Cailliau <Di...@eXplio.com> on 2002/11/06 15:33:59 UTC

(correction)

... 
params.addElement(new Parameter("command",
com.dewildecbt.util.OperationCommand.class, new
com.dewildecbt.util.OperationCommand("hashCode",new Object[]{}), null));
... 

(i used the BeanSerializer to serialize OperationCommands)

Re: (correction)

Posted by Alex Dovlecel <do...@kbs.twi.tudelft.nl>.

I have not followed your discution because I just got connected to the 
mailing list, but as far as I can remember, we have some major problems with 
the fact that SOAP does not support polymorphism. There is a fix, but for 
this you must change some code (like adding 2 lines) into RPCRouter (I think) 
file. 

If you are interested, then tell me and I will look for this. The correction 
is like this: 
if the return object is not null then 
	try to use the Class of the object and encode it by its class, 
else 
	just encode a null object based on the signature of the method. 

There is a flow even with this approach. If you have an Base object and a 
Child extends Base. You have the BAse object registered to a serializer, but 
the Child is not, then, if you are gonna return the Child instead of the 
Base, it will just tell you that you have not registered the Child object!!! 
Fault : correct. 

So you have to register the Child object and then it works. 


Hope it helps
dovle


> FYI, I will be looking at the code that resolves methods, as it looks to
> me like it was written to try to handle polymorphism, yet there are
> complaints that polymorphism is not working.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Scott Nichol" <sn...@scottnichol.com>
> To: <so...@xml.apache.org>
> Sent: Wednesday, November 06, 2002 10:05 AM
> Subject: Re: (correction)
>
> > Apache SOAP does not handle polymorphism when finding signatures.  It
> > could, but it doesn't right now.
> >
> > Scott Nichol
> >
> > ----- Original Message -----
> > From: "Dieter Cailliau" <Di...@eXplio.com>
> > To: <so...@xml.apache.org>
> > Sent: Wednesday, November 06, 2002 9:33 AM
> > Subject: (correction)
> >
> > > ...
> > > params.addElement(new Parameter("command",
> > > com.dewildecbt.util.OperationCommand.class, new
> > > com.dewildecbt.util.OperationCommand("hashCode",new Object[]{}),
> >
> > null));
> >
> > > ...
> > >
> > > (i used the BeanSerializer to serialize OperationCommands)
> >
> > --
> > 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: (correction)

Posted by James Black <jb...@ieee.org>.

Scott Nichol wrote:

> I have run some tests on the code that determines the method to invoke
> for a service, and in my tests polymorphism is handled properly.
> Therefore, you and others who have reported problems may have hit a bug
> that my tests have not.
>
> From your posts, I assume you have
>
> interface com.dewildecbt.util.Command{...}
> class com.dewildecbt.util.OperationCommand implements
> com.dewildecbt.util.Command{...}
>
> Are there any other subclasses or interfaces?
> What is the signature of the method that you think should be executed?
> What is your deployment descriptor?

  I am not certain, but this problem may be related to a bug report that I
filed. The problem is that when there are certain overloaded method
signatures, at some point there is a problem on the on-the-fly wsdl
generation. There will be one extra method that wasn't actually in the
original file.

--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>