axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norman, Eric" <enor...@Netegrity.com>
Subject RE: Proposed changes to OperationDesc
Date Wed, 11 Dec 2002 17:41:39 GMT
I honestly don't see how that would help.  The main obstacle is getting the
generated WSDL to omit the offending parameter.  To get that to happen, you
either have to change the description of the operation before generating the
WSDL or do some heavy lifting in the WSDL Emitter.

-----Original Message-----
From: Russell Butek [mailto:butek@us.ibm.com]
Sent: Wednesday, December 11, 2002 5:40 AM
To: axis-dev@xml.apache.org
Subject: Re: Proposed changes to OperationDesc






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"

                      <enorman@Netegrit        To:       "Axis-Dev (E-mail)"
<axis-dev@xml.apache.org>                            
                      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




Mime
View raw message