I'll apply the patch, thanks....
> Also I wouldn't mind knowing if there is a reason why the
> HolderOutInterceptor adds the objects based on the part index.
Everything should be using the index stored in the part and not the parts
location in the iterator. It's kind of important. There are
many "sources" of the objects, especially when dealing with the
wrapped/unwrapped conversion, but also things like in-band headers, out
of band headers, soap w/ attachements, etc... Up front, we go through
and make sure each part is assigned a unique index into the list so that
we can be sure that they are not clobbering each other.
Prior to 2.0.3 (maybe 2.0.2), we didn't do that. We did try and just
use it's index in the message, but that caused all kinds of problems,
especially around headers and the process of converting from wrapped to
unwrapped and back. For example:
With a (wrapped, not bare) method like:
int doFoo(@WebParam(header = true) int a,
String b)
"a" must have index 0, b must have index 1 as that is the order they need
to be in to call method.invoke().
However, the part order in the wsdl MUST have the generated wrapper
first, then the header. (doc/lit/wrapped requirement). Thus, the
wrapper stuff would be first in the part list, but would need to be last
in the index and vice versa.
Dan
On Wednesday 20 February 2008, Nolan, Edell wrote:
> Basically I was trying to do some integration of cxf with servicemix
> and my use case is using a java first client and when I try to invoke
> my operation it fails because the operation only gets back the return
> value and I also expect an inout parameter to be updated.
>
> It seems that in the HolderOutInterceptor it seems to add the objects
> into the MessageContentList based on the part index value which means
> the objects will not be in sequential order in the array.
>
>
>
> I attached the updated fix to the jira to get the objects based on the
> part index.
>
>
>
> If someone could apply my patch that would be great ?
>
>
>
> Also I wouldn't mind knowing if there is a reason why the
> HolderOutInterceptor adds the objects based on the part index.
>
>
>
> 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
[EMAIL PROTECTED]
http://www.dankulp.com/blog
