They both look like bugs to me. Log some issues and patches are ALWAYS
welcome. :-)
Dan
On Wednesday, August 17, 2011 4:19:13 PM Jesse Pangburn wrote:
> Hi,
> I found the cause of the problem to be a bug in this method in CXF (I have
> version 2.4.1): private Map<String, QName>
> createPayloadEleOpNameMap(BindingInfo bindingInfo) { Map<String, QName>
> payloadElementMap = new java.util.HashMap<String, QName>(); for
> (BindingOperationInfo bop : bindingInfo.getOperations()) {
> SoapOperationInfo soi =
> (SoapOperationInfo)bop.getExtensor(SoapOperationInfo.class); if (soi !=
> null) {
> if ("document".equals(soi.getStyle())) {
> // if doc
> if (bop.getOperationInfo().getInput() != null
> &&
> !bop.getOperationInfo().getInput().getMessageParts().isEmpty()) { QName qn
> = bop.getOperationInfo().getInput().getMessagePartByIndex(0)
> .getElementQName();
> payloadElementMap.put(qn.toString(),
> bop.getOperationInfo().getName()); }
> } else if ("rpc".equals(soi.getStyle())) {
> // if rpc
>
> payloadElementMap.put(bop.getOperationInfo().getName().toString(),
> bop.getOperationInfo() .getName());
> }
> }
> }
> return payloadElementMap;
> }
>
> The problem is that it requires the SoapOperationInfo to have a style
> attribute, but in the W3C spec for WSDL it says the style attribute on the
> soap operation is optional, specifically ' If the attribute is not
> specified, it defaults to the value specified in the soap:binding element.
> If the soap:binding element does not specify a style, it is assumed to be
> "document".' So the code needs to check if the soi has a style and if not
> read it from the binding and if not then set it as "document". This is not
> a problem in the WSDLs generated by CXF (as I found out with a HelloWorld
> test) because it creates these optional style attributes, but since W3C
> says people can generate WSDLs without these (and I ran into one) I think
> it's worth fixing.
>
> Unless someone disagrees, I'll create a defect for this and contribute a
> patch.
>
> While reading code and stepping through the debugger to find out where this
> was going wrong, I also found that if you use a SOAPMessage instead of a
> Source then the following function fails (ignoring the exception) and your
> ws-addressing action doesn't get set either- if you have any whitespace
> after the soap:body element before your first payload element: private
> String getPayloadElementName(SOAPMessage soapMessage) { try {
> SOAPElement element =
> (SOAPElement)soapMessage.getSOAPBody().getChildElements().next(); return
> new QName(element.getNamespaceURI(), element.getLocalName()).toString(); }
> catch (Exception e) {
> //ignore
> }
> return null;
>
> }
>
> This fails because the .next() call at the end gets a text node instead of
> an element object so the cast fails. So inexplicably your ws-addressing
> action header doesn't get set in this case either. Unless someone
> disagrees, I'll create a defect for this as well and contribute a patch.
>
> Thanks so much for your help! I wouldn't have gone looking and found this
> out without knowing it *should* work.
>
> Jesse
>
> -----Original Message-----
> From: Jesse Pangburn
> Sent: Wednesday, August 17, 2011 11:17 AM
> To: 'Daniel Kulp'; [email protected]
> Subject: RE: dispatch api with ws-addressing
>
> Hi Dan,
> Thanks for the suggestion, I'm trying to figure out one of those cases. I
> changed the code to this to try a DOMSource instead: Dispatch<Source> disp
> = service.createDispatch(new QName("urn:ihe:iti:xds-b:2007",
> "DocumentRegistry_Port_Soap12"), Source.class, Service.Mode.PAYLOAD, new
> AddressingFeature()); InputStream is =
> IBServer.class.getResourceAsStream("RegistryQuery.xml"); Document doc =
> XMLUtils.parse(is);
> DOMSource reqMsg = new DOMSource(doc);
> Source response = disp.invoke(reqMsg);
>
> DOMSource also sent the same wrong action header. I see that I get back a
> StaxSource (CXF StaxSource, not javax StAXSource) in this case so I tried
> using that as the input next: Dispatch<Source> disp =
> service.createDispatch(new QName("urn:ihe:iti:xds-b:2007",
> "DocumentRegistry_Port_Soap12"), Source.class, Service.Mode.PAYLOAD, new
> AddressingFeature()); InputStream is =
> IBServer.class.getResourceAsStream("RegistryQuery.xml"); XMLInputFactory
> xmlInputFactory = XMLInputFactory.newFactory();
> XMLStreamReader xmlStreamReader =
xmlInputFactory.createXMLStreamReader(is,
> "UTF-8"); StaxSource staxSource = new StaxSource(xmlStreamReader);
> Source response = disp.invoke(staxSource);
>
> StaxSource also sent the same wrong action header. I also tried SAXSource:
> InputSource inputSource = new InputSource(is);
> SAXSource saxSource = new SAXSource(inputSource);
> Source response = disp.invoke(saxSource);
>
> And lastly I tried javax's StAXSource:
> //StaxSource staxSource = new StaxSource(xmlStreamReader);
> StAXSource staxSource = new StAXSource(xmlStreamReader);
> Source response = disp.invoke(staxSource);
>
> I thought maybe one of these was one of the cases you referred to, but
> assume I misunderstood or am doing something else wrong. Or maybe this
> only works in soap 1.1 wsdls or something?
>
> Thanks,
> Jesse
>
> -----Original Message-----
> From: Daniel Kulp [mailto:[email protected]]
> Sent: Wednesday, August 17, 2011 10:29 AM
> To: [email protected]
> Cc: Jesse Pangburn
> Subject: Re: dispatch api with ws-addressing
>
> On Wednesday, August 17, 2011 12:15:53 PM Jesse Pangburn wrote:
> > Hi,
> > Thanks for the suggestion, that will work. I was hoping there was some
> > way for CXF to do it automatically from the WSDL and the message body,
> > but this manual step is at least simple and makes sense.
>
> In SOME cases it can, but I'm not sure if StreamSource is one of them.
>
> Another option is:
>
> disp.getRequestContext().put(MessageContext.WSDL_OPERATION,
> new QName(ns, "myOperation")
>
> which will tell CXF what operation that dispatch is mapped to.
>
> One note: you may want to switch from StreamSource to just "Source" if
> possible. StreamSource is really the worse of the possible source types
> from a performance standpoint. On the incoming side, we pretty much suck
> the message into a byte[] or file and re-wrapper that with a new parser.
> Kind of crappy. If you do Provider<Source>, you would likely get a
> subclass of SAXSource which would allow us to maintain some level of
> streaming.
>
> Dan
>
> > Thank you,
> > Jesse
> >
> > -----Original Message-----
> > From: Aki Yoshida [mailto:[email protected]]
> > Sent: Wednesday, August 17, 2011 2:09 AM
> > To: [email protected]
> > Subject: Re: dispatch api with ws-addressing
> >
> > Hi,
> > you need to set the soap action in the dispatch client's request
> > context.
> > In your case, you need to add the following line:
> >
> > disp.getRequestContext().put(BindingProvider.SOAPACTION_URI_PROPERTY,
> > "urn:ihe:iti:2007:RegistryStoredQuery") ;
> >
> > Regards, aki
> >
> > 2011/8/17 Jesse Pangburn <[email protected]>:
> > > Hi,
> > > I'm trying to use the dispatch API and while I can make the service
> > > call ok, the ws-address "action" header is wrong. Here's my code:
> > > URL wsdlURL = new
> > > URL("file:/home/jpangburn/Desktop/IHE/XDSb.Support.Materials.v9/wsdl
> > > /XD
> > > S.b_DocumentRegistry.wsdl"); Service service =
> > > Service.create(wsdlURL,
> > > new QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Service"));
> > > Dispatch<StreamSource> disp = service.createDispatch(new
> > > QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Port_Soap12"),
> > > StreamSource.class, Service.Mode.PAYLOAD, new AddressingFeature());
> > > InputStream is =
> > > IBServer.class.getResourceAsStream("RegistryQuery.xml");
> > > StreamSource
> > > request = new StreamSource(is);
> > >
> > > StreamSource response = disp.invoke(request);
> > >
> > > Basically, I try to create a service from a WSDL with the service
> > > QName, then create a Dispatch from the port's QName while passing
> > > "new AddressingFeature()" to turn on WS-Addressing. The action
> > > header comes out like this: <Action
> > > xmlns="http://www.w3.org/2005/08/addressing";>http://cxf.apache.org/j
> > > axw
> > > s/dispatch/DocumentRegistry_PortType/InvokeRequest</Action>
> > >
> > > This is wrong because the SOAP12 binding's operation has the
> > > following:
> > > <soap12:operation
> > > soapAction="urn:ihe:iti:2007:RegistryStoredQuery"/>
> > >
> > > So the header should be:
> > > <Action
> > > xmlns="http://www.w3.org/2005/08/addressing";>urn:ihe:iti:2007:Regist
> > > ryS
> > > toredQuery</Action>
> > >
> > > All I can guess is that the Dispatch API doesn't know which
> > > operation
> > > I'm calling so it makes up this generic action header for the port
> > > instead of looking at the message I'm sending, determining the
> > > operation called, and grabbing the correct soap action to use in the
> > > action header. Am I doing something wrong or is this a limitation
> > > in
> > > the Dispatch API's support for WS-Addressing?
> > >
> > > Thanks,
> > > Jesse
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
