[prev in list] [next in list] [prev in thread] [next in thread] 

List:       soap-dev
Subject:    RE: Patch to RPCRouter.java
From:       "Matthew J. Duftler" <duftler () watson ! ibm ! com>
Date:       2001-05-30 18:34:15
[Download RAW message or body]

Hi Matthew,

This feels to me like something that should be implemented by a Provider. That would \
also be a way you could deliver it to your clients without them having to apply a \
patch and re-compile things. They would just need to make your \
CustomParameterProvider available on their classpath, and configure the deployment \
descriptors to specify the type of the provider.

Thanks,
-Matt

> -----Original Message-----
> From: Matthew Booth [mailto:matthew@arsdigita.com]
> Sent: Wednesday, May 23, 2001 9:33 AM
> To: soap-dev@xml.apache.org
> Subject: Patch to RPCRouter.java
> 
> 
> I actually mailed this straight to Sanjiva. Not sure if I was 
> supposed to do 
> that. If not, sorry!
> 
> This is a really small patch to RPCRouter.java which allows you 
> to declare a 
> method with signature: methodName(Parameter params[]) which will 
> be passed an 
> array containing Parameter objects to be passed to it. This is 
> matched after 
> the regular matching and methodName(SOAPContext, ...) so it 
> doesn't affect 
> existing code.
> 
> The idea is to allow you to implement a handler which doesn't 
> have to know what 
> arguments it's going to get. Specifically, I'm wrapping up a 
> bunch of PL/SQL 
> functions in SOAP and I want to be allow a client to not send 
> parameters which 
> are default in the PL/SQL. It also occurs to me that if you don't want to 
> constrain the order of arguments passed in this could be useful.
> 
> Silly question now we're on rc releases: any chance this could 
> make 2.2? This 
> would make my life much easier. Try telling a client they have to 
> download the 
> source, patch it and compile it themselves...
> 
> I have attached the patch. If that doesn't work for people, let 
> me know. Using 
> crappy web mail client because of client's oppressive firewall...
> 


[prev in list] [next in list] [prev in thread] [next in thread]