axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shantanu Sen <s...@pacbell.net>
Subject Re: interfaces as params?
Date Tue, 27 May 2003 19:31:23 GMT
I could not get the code sample that you said was
attached. Can you please re-send it? It would give me
an idea how to programmatically deploy the mappings.

Thanks,
Shantanu Sen


--- Rodrigo Ruiz <rruiz@gridsystems.com> wrote:
> RE: interfaces as params?In my experience, you can
> use interfaces as parameters and return types. Axis
> should successfully map any class implementing the
> interface to the interface itself.
> For your client code, if WSDL2Java does not fit, I
> would create stub classes for the server interfaces,
> and manually correct the generated code to use them.
> 
> I'm doing something similar in the project I'm
> working in, although I deploy all my services and
> type mappings programmatically. In my case, I have a
> class implementing many interfaces. My services use
> the interfaces as both return types and parameters,
> and in all cases I'm getting the correct WSDL and
> response envelopes, so I guess all works correctly
> at the server side :-)
> 
> I added an attach with a bit of code I use to deploy
> my mappings. Perhaps you can translate it to wsdd
> syntax.
> Basically, the idea is to register, for the same
> type, the interface only for serialization, and the
> class for both serialization and deserialization.
> The order of the registry is important, as the
> interface entry must be found before the class one.
> 
> If you have many classes implementing the same
> interface, deserialization will allways instantiate
> objects of the same class (the first found in the
> registry that matches the requested type), as Axis
> will not have any mean to determine which
> implementation it has to use. I don't know of any
> general solution to this problem.
> 
> Anyway, as I'm doing the deployment through internal
> code, I'm not sure you can get the same results
> through wsdd file, sorry
> 
> Hope this helps!
> Rodrigo Ruiz
>   ----- Original Message ----- 
>   From: Volkmann, Mark 
>   To: 'axis-user@ws.apache.org' 
>   Sent: Friday, May 23, 2003 9:21 PM
>   Subject: RE: interfaces as params?
> 
> 
>   The client certainly needs to have bytecode for
> the parameter and return type classes available, but
> why can't the parameter and return types of the
> service implementation (and the client-side proxy)
> be interface types?  I'm pretty sure that Axis
> doesn't support this.
> 
>   What I'd expect is that Java2WSDL would take a
> service implementation that used interface types for
> parameter/return types and generate type
> descriptions in the WSDL by looking for get methods
> (Java Bean pattern).  I don't believe Axis currently
> does this.  Someone please correct me if I'm wrong.
> 
>   > -----Original Message----- 
>   > From: David Green
> [mailto:david.green@maketechnologies.com] 
>   > Sent: Friday, May 23, 2003 1:52 PM 
>   > To: axis-user@ws.apache.org 
>   > Subject: RE: interfaces as params? 
>   > 
>   > 
>   > From my experience, the client-generated code
> will have classes for 
>   > these complex types, not interfaces. 
>   > 
>   > David 
>   > 
>   > -----Original Message----- 
>   > From: Shantanu Sen [mailto:sdsen@pacbell.net] 
>   > Sent: Friday, May 23, 2003 11:37 AM 
>   > To: axis-user@ws.apache.org 
>   > Subject: RE: interfaces as params? 
>   > 
>   > 
>   > Custom (de)serializers can be specified in the
> WSDD at 
>   > the time of deployment of the Service. This is a
> one 
>   > time thing and fine for the server. 
>   > 
>   > But this also means that any client has to
> supply 
>   > these at the time of invoking the service right?
> 
>   > 
>   > Shantanu Sen 
>   > 
>   > --- David Green
> <david.green@maketechnologies.com> 
>   > wrote: 
>   > > I encountered this same problem.  I ended up
> writing 
>   > > a custom 
>   > > serializer/deserializer that subclassed from
> the 
>   > > Bean 
>   > > serializer/deserializers to do support my 
>   > > interfaces. 
>   > > 
>   > > David 
>   > > 
>   > > -----Original Message----- 
>   > > From: Shantanu Sen [mailto:sdsen@pacbell.net] 
>   > > Sent: Wednesday, May 21, 2003 5:11 PM 
>   > > To: axis-user@ws.apache.org 
>   > > Subject: interfaces as params? 
>   > > 
>   > > 
>   > > I have an interface as follows: 
>   > > 
>   > > public interface MyOperation extends
> java.rmi.Remote 
>   > > { 
>   > > 
>   > > public MyComplex testOperation(java.util.Map
> map, 
>   > >                            MyDoc[] docs)
> throws 
>   > >                      java.rmi.RemoteException;
> 
>   > > } 
>   > > 
>   > > where MyDoc is defined as: 
>   > > 
>   > > public interface MyDoc { 
>   > > 
>   > > public String getName(); 
>   > > public byte[] getBytes(); 
>   > > 
>   > > } 
>   > > 
>   > > and MyComplex is a concrete class: 
>   > > 
>   > > public class MyComplex implements Serializable
> 
>   > > { 
>   > >   Map header; 
>   > >   MyDoc[] payload; 
>   > > } 
>   > > 
>   > > 
>   > > 
>   > > Can I  expose MyOperation as a service
> endpoint? 
>   > > 
>   > > JAX-RPC states that there can be complex java 
>   > > classes 
>   > > as a parameter/return type. But what about 
>   > > interfaces? 
>   > > When I do a Java2WSDL, the MyDoc is written
> out as xsd:anyType. But 
>   > > the WSDL2Java will not know how to re-create
> the class from 
>   > > xsd:anyType right? Is there any way I can
> provide a mapping between 
>   > > the interface 
>   > > and a concrete class? If so how can I do that?
> 
>   > > 
>   > > Is there any way we can have interfaces as
> method 
>   > > parameters with AXIS using RPC? 
>   > > 
>   > > Thanks, 
>   > > Shantanu Sen 
>   > 
> 
> 
> 
>  
>
***********************************************************************************
>   WARNING: All e-mail sent to and from this address
> will be received or
>   otherwise recorded by the A.G. Edwards corporate
> e-mail system and is
>   subject to archival, monitoring or review by,
> and/or disclosure to,
>   someone other than the recipient.
>  
>
************************************************************************************
> 


Mime
View raw message