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=yang >> >> 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. >
