cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: potential bug with the way DocLiteral matches its params to pick the correct operation.
Date Thu, 21 Feb 2008 14:48:33 GMT


I assume you are talking about doc/lit/bare service judging from the code 
path.   In that case, the bug is logged at:

https://issues.apache.org/jira/browse/CXF-1073

That said, it's not really a high priority as such a service would not be 
WSI-BP compliant and you're likely to run into all kinds of 
interopability issues.   WSI-BP mandates one "part" per message in the 
wsdl for doc/lit.   

One reason it's "hard" to support is that it would completely break 
streaming of reading the parts.   We would pretty much need to suck in 
the entire soap message, look at all the top level element names to 
match the parts to the operation, then finally read into the proper 
types.   Preformance would kind of suck.


My suggestion would be to switch it to a default wrapped doc/lit form.

That said, another workaround would be to add a unique soap action to 
each operation.   The SOAPActionInInterceptor can then determine the 
operation ahead of time.    Again, it's out of WSI-BP spec so you may 
run into issues with other toolkits.

Dan



On Thursday 21 February 2008, Nolan, Edell wrote:
> Hi,
>
>
>
> I am trying to verify that this is a bug before I create a jira.
>
>
>
> I have a PortType that has two operations and I have implemented a
> Soap binding using Document Literal.
>
>
>
> String Op1(Type1);
>
> String Op2(Type1, inout Type2)
>
>
>
> When I try to invoke the first operation -The server side trys to
> execute Op2 and not op1.
>
>
>
> Basically what appears to be happening is it is trying to match the
> first parameter and when it gets that match - it chooses the operation
> and continues. It searches through the list of operations and in this
> case op2 is first in the list so the first param will match.
>
>
>
> The code where I see this happening is
>
>
>
> It does a call from the DocLiteralInInterceptor.java
>
>
>
>   if (msgInfo != null && msgInfo.getMessageParts() != null
>
>                     && msgInfo.getMessageParts().size() > 0) {
>
>                     assert msgInfo.getMessageParts().size() >
> paramNum;
>
>                     p = msgInfo.getMessageParts().get(paramNum);
>
>                 } else {
>
>                     p = findMessagePart(exchange, operations, elName,
> client, paramNum);
>
>                 }
>
>
>
> .....
>
>
>
> In AbstractInDatabindingInterceptor.java
>
>
>
>   protected MessagePartInfo findMessagePart(Exchange exchange,
> Collection<OperationInfo> operations,
>
>                                               QName name, boolean
> client, int index) {
>
>         Endpoint ep = exchange.get(Endpoint.class);
>
>         MessagePartInfo lastChoice = null;
>
>         for (Iterator<OperationInfo> itr = operations.iterator();
> itr.hasNext();) {
>
>             OperationInfo op = itr.next();
>
>
>
>             BindingOperationInfo boi =
> ep.getEndpointInfo().getBinding().getOperation(op);
>
>             if (boi == null) {
>
>                 continue;
>
>             }
>
>             BindingMessageInfo msgInfo = null;
>
>             if (client) {
>
>                 msgInfo = boi.getOutput();
>
>             } else {
>
>                 msgInfo = boi.getInput();
>
>             }
>
>
>
>             if (msgInfo == null) {
>
>                 itr.remove();
>
>                 continue;
>
>             }
>
>
>
>             Collection bodyParts = msgInfo.getMessageParts();
>
>             if (bodyParts.size() == 0 || bodyParts.size() <= index) {
>
>                 itr.remove();
>
>                 continue;
>
>             }
>
>
>
>             MessagePartInfo p =
> (MessagePartInfo)msgInfo.getMessageParts().get(index);
>
>             if (name.getNamespaceURI() == null ||
> name.getNamespaceURI().length() == 0) {
>
>                 // message part has same namespace with the message
>
>                 name = new
> QName(p.getMessageInfo().getName().getNamespaceURI(),
> name.getLocalPart());
>
>             }
>
>             if (name.equals(p.getConcreteName())) {
>
>                 exchange.put(BindingOperationInfo.class, boi);
>
>                 exchange.put(OperationInfo.class,
> boi.getOperationInfo());
>
>                 exchange.setOneWay(op.isOneWay());
>
>                 return p;
>
>             }
>
>
>
>             if (XSD_ANY.equals(p.getTypeQName())) {
>
>                 lastChoice = p;
>
>             } else {
>
>                 itr.remove();
>
>             }
>
>         }
>
>         return lastChoice;
>
>     }
>
>
>
>
>
> Should it also try to match the number of params as well or is this a
> requirement
>
> where all the parameters need to be different ?
>
>
>
>
>
> Thanks, Edell.
>
>
>
>
>
>
>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message