You could create wrapper classes for each one where those new classes add
the extra param for you (heck you could even automate the process that
creates them based on the list of classes/methods you want to expose).
True that's annoying but to me changing Axis is more annoying since I
believe Axis should discourage people from doing the type of coding you've
already done. While for you it might not have been that hard you probably
had to learn more about the internals of Axis than you would have liked (or
IMO should have been forced to). If Axis' docs/user's-guide gave clean
solutions to these types of problems that didn't require more in-depth
knowledge than possibly "how to write a handler" then I think the user
community would be happier. I view overriding the methods mentioned in
this thread as a very advanced topic/solution while the problem you've
described isn't. IMO.
-Dug
"Norman, Eric" <[EMAIL PROTECTED]> on 12/11/2002 01:08:45 PM
To: Doug Davis/Raleigh/IBM@IBMUS
cc:
Subject: RE: DO NOT REPLY [Bug 15284] New: - Proposed modification to
Oper ationDesc
The classes we are exposing as webservices are dual-use classes and we
would
rather not have to modify all our business logic classes to make axis
happy.
It seems to me that it is up to the provider to determine how to call the
method. In our case, in the invokeMethod(..) method of our provider we
resize the argValues array that is passed in, add our extra parameter where
appropriate (in our case the 1st parameter), call the method and return the
result.
-----Original Message-----
From: Doug Davis [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 11, 2002 9:55 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: DO NOT REPLY [Bug 15284] New: - Proposed modification to
OperationDesc
Wouldn't a cleaner solution be to do what we do for the messageContext,
which is stick it in some ThreadLocal data. You have a solution for adding
a 1st parameter, but what if someone wants to add it at the end, or in the
middle. Placing it in ThreadLocal storage would not require any changes to
the WSDL. You can have a server side handler "set" the data and then in
your app just "get" it - no changes require to Axis.
-Dug
[EMAIL PROTECTED] on 12/11/2002 12:51:30 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: DO NOT REPLY [Bug 15284] New: - Proposed modification to
OperationDesc
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15284>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15284
Proposed modification to OperationDesc
Summary: Proposed modification to OperationDesc
Product: Axis
Version: 1.0
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component: Basic Architecture
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
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());
}
}
