I agree that providing a wrapper would be the easiest way if I only had a
few methods that needed to be wrapped.  However, I would prefer to not do
that because the requirements of the project are to automatically expose the
methods as webservices without a lot of extra development work.  We did
something similar using Apache SOAP 2.x and our own WSDL generation
mechanism, but we would like to migrate to Axis.  I'll do some more digging.

-----Original Message-----
From: Dennis Sosnoski [mailto:dms@;sosnoski.com]
Sent: Monday, November 11, 2002 8:56 PM
To: [EMAIL PROTECTED]
Subject: Re: Customizing the WSDL generation.


Hi Eric,

The cleanest way to do this is to create a wrapper for the Java methods 
you want to expose, leaving out the extra parameter from the method 
definitions in the wrapper. One convenient way of doing the whole job is 
to first run Java2WSDL on your basic methods, then edit the generated 
WSDL to delete the first parameter from every call, and finally run 
WSDL2Java to generate both client- and server-side code that matches the 
WSDL. The server-side code will include a skeleton you can use as your 
wrapper.

Hope that helps. BTW, I'm just down the road in Redmond if you need some 
help. ;-)

  - Dennis

Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support
http://www.sosnoski.com

Norman, Eric wrote:

>I have a web application that needs to expose a set of java methods as
>webservices.  However, the first parameter to each java method needs to be
>supplied by the application on the server side (i.e. not supplied by the
>client in the SOAP envelope).  I see how I can override the 'invokeMethod'
>method in the RPCProvider to inject the objects into the method argument
>array before invoking the method.  That seems like it would work ok.
>However, I would prefer that the clients of the webservice not know about
>the server-side parameter (in the WSDL).  I will probably try to subclass
>the WSDL generation classes to exclude the offending 'server-side supplied'
>arguments from the input message.  However, I'm concerned that the change
>might cause some undesirable side-effects.  Has anyone tried to do anything
>like this before?  If so, what are the pitfalls?
>
>. . . . . . . . . . . . . . . . . . . . . . . . 
>
>Eric Norman | Software Engineer
>
>600 108th Avenue NE | Suite 900 | Bellevue WA  98004
>      T 425.462.1999 x4165 |  F 425.637.1192 | [EMAIL PROTECTED]
>w w w . n e t e g r i t y . c o m
>
>  
>

Reply via email to