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.
