Great, thanks I'll see how it goes... -Chris W.
-----Original Message----- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2008 2:09 PM To: [email protected] Cc: Wolf, Chris (IT) Subject: Re: ArrayIndexOutOfRange exception problem in URIMappingInterceptor Chris, We'd definitely be open to a patch. :-) Dan On Tuesday 12 August 2008 11:20:07 am Wolf, Chris (IT) wrote: > Benson, > > We can look at that, but more generally, I was hoping to see the > URIMappingInterceptor ignore GET parameters that were not in the WSDL. > > > Thanks, > > -Chris W. > > -----Original Message----- > From: Benson Margulies [mailto:[EMAIL PROTECTED] > Sent: Friday, August 01, 2008 9:33 AM > To: [email protected] > Subject: Re: ArrayIndexOutOfRange exception problem in > URIMappingInterceptor > > How about using our JavaScript client generator to talk SOAP from the > browser? > > On Fri, Aug 1, 2008 at 9:25 AM, Wolf, Chris (IT) > > <[EMAIL PROTECTED]> wrote: > > We're not going to ditch SOAP because of the advantages of code > > generation from WSDL (top-down methodology), WS-* standards and > > features, etc. As long as our code only use JAX-WS APIs, we're not > > tied to a specific implementation. > > > > RESTful invocation is a minor use-case. The HTTP headers idea is an > > interesting idea, however, not workable if we want to invoke with a > > browser. (although the browser invocation use-case is just for > > testing, right now) > > > > Thanks, > > > > -Chris W. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > > Brad > > Sent: Friday, August 01, 2008 4:03 AM > > To: [email protected] > > Subject: Re: ArrayIndexOutOfRange exception problem in > > URIMappingInterceptor > > > > Hi, > > > > if you want to REST and a plain POST of an xml document then why not > > ditch SOAP altogether and use HTTP headers for your metadata? Both > > of your requirements are essentially XML over HTTP so why not use > > their common ground to your advantage. > > > > The schema part of your WSDL will still be valid so your interface > > "contract" is still there. Saves you have to do too much which ties > > your code to a specific implementation too. > > > > Brad. > > > > On Fri, Aug 1, 2008 at 3:05 AM, Wolf, Chris (IT) > > > > <[EMAIL PROTECTED]> wrote: > >> We want to deploy services that are consumable either via > >> conventional > >> > >> POST of a request document, or via RESTful invocation. It seems > >> that > >> > >> wrapped-doc/literal has the feature of being able to do that > >> without resorting to any extra work via the URIMappingInterceptor, > >> which is wired in by default. > >> > >> The trouble is that our request has some meta data that must be > >> added > >> > >> to the soap header, and in the case of conventional invocation via > >> POST of a request document, all is fine. > >> > >> Now we want to also be able to pass this meta data when performing > >> RESTful invocation, so the idea is to just tack on some extra query > >> string parameters, in addition to the operation parameters defined > >> in > >> > >> the WSDL. > >> > >> Ideally, the RESTful invocation processor would ignore the extra > >> parameters which are not in the WSDL, unfortunately, before > >> URIMappingInterceptor even gets a chance to complain, we get an > >> array > >> > >> index error. > >> > >> > >> protected MessageContentsList getParameters(Message message, > >> BindingOperationInfo operation) { > >> [...] > >> int idx = 0; > >> if (inf != null) { > >> idx = inf.getIndex(); > >> } > >> Class<?> type = types[idx]; <---- line #178, CXF-2.1.1 > >> (types is null for no-arg operation) > >> [...] > >> } > >> > >> I could subclass this interceptor and change the behavior of > >> getParameters(...) by override, > >> then somehow configure cxf to use the derived class. However, I > >> thought I'd ask the list - is this idea of simulating the Envelope > >> Header in RESTful invocation by exra parameters a good idea? > >> Obviously, there are limitations to what can be represented > >> compared to full hierarchical XML, but this can be partially > >> compensated for by > >> > >> a param name scheme such as: > >> group0.item0=foo&group0.item1=bar&group1.item0=yin&group1.item1=yan > >> g > >> > >> I would hate to have to muddy up our contract definitions in the > >> WSDL > >> > >> just to accommodate meta data that is only relevant to the > >> infrastructure, rather then specific business functionality. I ask > >> beause it might just be easier for me to patch > >> URIMappingInterceptor directly, but I wonder if the patch would be accepted. > >> > >> Thanks, > >> > >> -Chris W. > >> -------------------------------------------------------- > >> > >> NOTICE: If received in error, please destroy and notify sender. > >> Sender > > > > does not intend to waive confidentiality or privilege. Use of this > > email is prohibited when received in error. > > > > -------------------------------------------------------- > > > > NOTICE: If received in error, please destroy and notify sender. > > Sender > > does not intend to waive confidentiality or privilege. Use of this > email is prohibited when received in error. > > -------------------------------------------------------- > > NOTICE: If received in error, please destroy and notify sender. Sender > does not intend to waive confidentiality or privilege. Use of this > email is prohibited when received in error. -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
