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.

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

Reply via email to