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