Hi,
You might also want to consider combining the JAX-WS and JAX-RS on the server side, while still using WSDL on the client side - it
might work quite well, and it would likely make the server side more flexible with respect to dealing with various non-SOAP
requests...You might be able to preserve the same server side code when combining JAX-WS and JAX-RS
Cheers, Sergey
----- Original Message -----
From: "Wolf, Chris (IT)" <[EMAIL PROTECTED]>
To: "Daniel Kulp" <[EMAIL PROTECTED]>; <[email protected]>
Sent: Tuesday, August 12, 2008 8:30 PM
Subject: RE: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
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.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
