Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 13199 invoked by uid 500); 11 Dec 2002 13:48:57 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 13173 invoked from network); 11 Dec 2002 13:48:57 -0000 Subject: Re: Proposed changes to OperationDesc To: axis-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Russell Butek Date: Wed, 11 Dec 2002 07:40:14 -0600 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.0 [IBM]|November 8, 2002) at 12/11/2002 06:48:57 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Sounds to me like you should be using a handler to add a header to the soap message, not mucking with the description of the operation. Russell Butek butek@us.ibm.com "Norman, Eric" y.com> cc: Subject: Proposed changes to OperationDesc 12/10/2002 03:56 PM Please respond to axis-dev I'm working on an project where we want to expose our generic business logic classes as webservices. However, each of the methods in these classes expect the first parameter to be a server side (application context) object that should not be supplied by the client. A servlet filter creates the appContext object and makes it available for the server side classes to use (including our custom Axis Provider). In our custom Axis provider, we are overriding the invokeMethod(..) method to inject the appContext object into the argument array before invoking the method. That seems to work ok. However, the generated WSDL still has the offending (supplied on the server side) parameter in it which we don't want the client applications to have to worry about. Our initial thoughts on how to get rid of the parameter from the WSDL is to override the initServiceDesc(..) method in our custom Provider and remove the offending ParameterDesc from the OperationDesc object. Unfortunately, there doesn't seem to be any method available to remove a parameter from an OperationDesc. What we really want to do is to supply our own list of ParameterDesc objects (with the offending one removed). There was a partially implemented setParameters(..) call already in the OperationDesc class. To make our solution work, we fixed/completed the implementation of the setParameters(..) method and made it public. We are now able to remove the parameter from the WSDL (by overriding initServiceDesc(..) in our provider) and it seems to work. If there are no objections, I'd like to have someone add this patch to the main source tree. Below is the source for the method we had to modify. ----------------------- In OperationDesc.java: ----------------------- /** * Set the parameters wholesale. * * @param newParameters an ArrayList of ParameterDescs */ public void setParameters(ArrayList newParameters) { parameters = new ArrayList(); //Keep numInParams correct. numInParams = 0; for( java.util.ListIterator li= newParameters.listIterator(); li.hasNext(); ){ addParameter((ParameterDesc) li.next()); } } . . . . . . . . . . . . . . . . . . . . . . . . Eric Norman | Software Engineer 600 108th Avenue NE | Suite 900 | Bellevue WA 98004 T 425.462.1999 x4165 | F 425.637.1192 | enorman@netegrity.com w w w . n e t e g r i t y . c o m