On Thursday, March 22, 2012 01:12:56 PM Dickerson, Kyle B. wrote: > I see. Thanks for the explanation, I appreciate it. > > I am seeing the same issue when not using MIME but still using > attachments. > > I will try to configure my client to use the WSDL during the service > creation to see if that changes anything.
Actually, I just checked the grails plugin code: https://github.com/ctoestreich/cxf- client/blob/master/src/groovy/com/grails/cxf/client/WebServiceClientFactoryImpl.groovy and there doesn't seem to be any way to do it. There is nothing in there at all for dealing with WSDL's. You MAY be able to change your code to use the generated objects to create your proxies. Basically, the groovy equiv of: new mime.soapserver.TestServiceServicePorts(urlToWSDL).getTestServicePort(); Dan > > Thanks, > Kyle > > -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Thursday, March 22, 2012 12:51 PM > To: [email protected] > Cc: Dickerson, Kyle B. > Subject: Re: SwAInInterceptor failing to process attachment - no > SoapBodyInfo > On Thursday, March 22, 2012 09:00:27 AM Dickerson, Kyle B. wrote: > > Are you saying that I can't use wsdl2java to generate classes if I need > > to handle attachments in the responses? > > No, not at all. You definitely SHOULD be using the wsdl2java stuff. > > > What I'm saying is that at RUNTIME, the services and clients also need to > use the WSDL in order for the mime stuff to be taken into account. CXF > can kind of run in two modes: > > 1) Just use the .class stuff - for many use cases, CXF can use the > annotations on the class to generate proper messages, process things, > etc.. Unfortunately, mime isn't one of them. > > 2) Use the WSDL at runtime - if you configure in the wsdlLocation and such > so that the wsdl can be found when the client/service is created, then > CXF can use the extra information in the wsdl (such as mime stuff, > policies,etc...) > > In your case, the runtime NEEDS the wsdl, but according to the logs, it > isn't being configured in. I know nothing about how groovy creates or > configures the CXF clients. From the logs, the wsdlLocation that is being > passed in (if any) is null. Thus, it's going to mode 1. That is what > would need to be looked at and that may need a question off to the grails > list or something. > > Dan > > > -Kyle > > > > -----Original Message----- > > From: Daniel Kulp [mailto:[email protected]] > > Sent: Wednesday, March 21, 2012 7:12 PM > > To: [email protected] > > Cc: Dickerson, Kyle B. > > Subject: Re: SwAInInterceptor failing to process attachment - no > > SoapBodyInfo > > > > > > I'll try and take a closer look in the upcoming days, but a quick look > > in > > the log you sent showed: > > > > Creating Service ....... from class ....... > > > > Basically, it's not using a WSDL for anything. Thus, none of the mime > > extensors from the WSDL would be available. I haven't looked at the > > code > > or anything yet, but that's the first thing you should figure out: get > > it > > using the wsdl, not the classes. > > > > > > Dan > > > > On Wednesday, March 21, 2012 03:32:42 PM Dickerson, Kyle B. wrote: > > > Christian put the sample client + servers I made up on GitHub: > > > https://github.com/ctoestreich/soapClient > > > > > > He's the author of the Grails plugin (cxf-client) that I'm using. > > > > > > The demo provides 4 very simple SOAP servers (1 MIME attachments, 1 > > > non-MIME attachments, 1 Holders but no attachments, 1 no holders). I > > > followed this guide to create them from handmade WSDLs: > > > http://cxf.apache.org/docs/developing-a-service.html > > > > > > It also has a Grails 1.3.7 client that uses the cxf-client plugin to > > > connect to the 4 SOAP servers and make a simple request that shows the > > > issue with the attachments. I realize that's probably inconvenient > > > for > > > people on this list, but GRAILS is simple to install (it's just an > > > unzip, > > > an environment variable, and a path entry) and then you should be able > > > to > > > run the client using "grails run-app" from the "soapClient" folder. > > > (The > > > 1.3.7 release can be downloaded here: > > > http://dist.springframework.org.s3.amazonaws.com/release/GRAILS/grails > > > -1 > > > . > > > 3.7.zip) > > > > > > > > > As for the logs: > > > > > > I have log4j set to 'all' for 'org.apache.cxf' but I don't see > > > anything > > > in the logs along the lines of "could not find service..." > > > > > > Dan, I'll send you a complete logging output offlist, maybe you'll be > > > able to see something helpful in it. I can provide any other debug > > > information desired. As I mentioned in an earlier post I injected a > > > custom interceptor which I'm using to extract all sorts of > > > information. > > > > > > -Kyle > > > > > > -----Original Message----- > > > From: Daniel Kulp [mailto:[email protected]] > > > Sent: Wednesday, March 21, 2012 2:52 PM > > > To: [email protected] > > > Cc: Dickerson, Kyle B. > > > Subject: Re: SwAInInterceptor failing to process attachment - no > > > SoapBodyInfo > > > > > > > > > Can you create a sample that demonstrates this? Can you also test > > > with > > > the latest 2.5.3-SNAPSHOT? Also, is there anything "interesting" in > > > the > > > logs? > > > > > > The symptom is very similar to > > > https://issues.apache.org/jira/browse/CXF-4106 where attachments were > > > getting "lost" due to the SoapBodyInfo and other mime things getting > > > "lost". I'd like to know if something in the logs was saying "could > > > not > > > find service..." or other message that would indicate it was creating > > > a > > > new binding. If so, 2.5.3-SNAPSHOT *MIGHT* already fix it. > > > > > > Dan > > > > > > On Wednesday, March 21, 2012 01:57:40 PM Dickerson, Kyle B. wrote: > > > > This topic was previously: "CXF as Client - Response Attachment - > > > > HolderInInterceptor IndexOutOfBoundsException" > > > > > > > > But this subject better represents the true issue > > > > > > > > > > > > > > > > SwAInInterceptor is failing to handle the attachment because > > > > SoapBodyInfo > > > > is null. > > > > > > > > The relevant code from SwAInInterceptor.java is: > > > > > > > > > > > > > > > > BindingOperationInfo bop = > > > > message.getExchange().getBindingOperationInfo() > > > > > > > > if (bop.isUnwrapped()) {bop = bop.getWrappedOperation()} > > > > > > > > boolean client = isRequestor(message) // client == true > > > > > > > > BindingMessageInfo bmi = client ? bop.getOutput() : bop.getInput() > > > > > > > > SoapBodyInfo sbi = bmi.getExtensor(SoapBodyInfo.class) > > > > > > > > > > > > > > > > sbi is null at this point and a null check stops execution. So > > > > messageContentsList is not populated with the attachment as it > > > > should > > > > be. > > > > > > > > > > > > > > > > Using reflection to investigate the BindingMessageInfo object I > > > > learn: > > > > > > > > 1. No delegate is in use. > > > > > > > > 2. The only extensor available is "SOAPBody > > > > ({http://schemas.xmlsoap.org/wsdl/soap/}body): required=null > > > > use=literal". > > > > > > > > 3. Don't know if this is relevant, if I ask the SOAPBody extensor > > > > its > > > > class I get "$Proxy42" > > > > > > > > > > > > > > > > Since no extensor match is found for a SoapBodyInfo class we get a > > > > null > > > > value returned, so sbi is null. > > > > > > > > > > > > > > > > Anyone have any thoughts on why SoapBodyInfo is coming back null? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Kyle -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
