I'm using Grails with the cxf-client plugin, but I don't know whether the issue is with the plugin or not. I'm already communicating with the plugin author, but I'm hoping someone here can shine some light on the situation. This is for WSDL-first code using wsdl2java to generate the client classes.
I'm working with a service that returns some data as an attachment. The response looks fine and the attachmentInInterceptor seems to work fine (the attachment is accessible from message.getAttachments()) however, when HolderInInterceptor runs it seems to be looking for the attachment in the MessageContentsList and it's not there. I've stuck a custom Interceptor in just before the HolderInInterceptor runs so that I can inspect what's going on. So what I'm seeing is that the MessageContentsList contains what it should (I assume) and the attachment is available via message.getAttachments(). The MessagePartInfo list has an entry for the responseObject which works fine and the Holder for that is correctly populated. But the MessagePartInfo list contains an entry for the attachment, it pulls up the Holder for the attachment, but then there's nothing in MessageContentsList to populate it with, which is where it throws the IndexOutOfBoundsException (HolderInInterceptor.java:65). Does this suggest there's something wrong with the generated classes? I've already built a set of example servers and a client to talk to them that shows this issue is only occurring when attachments and holders are used. If I have holders without an attachment there is no issue. I can get this example to anyone interested. For the example servers I used the same WSDL to generate the server classes. It looks like I can "make it work" by sticking the attachment into the MessageContentsList before the HolderInInterceptor runs, in which case the code gets through all the interceptors and back to my code, but then the thing in my Holder is not the correct type (should be byte[], instead I'm getting a LoadingByteArrayOutputStream). I assume this is altogether a bad idea regardless. Thanks, Kyle
