Hey!

The method as generated from the wsdl is as follows:

    @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
    @WebMethod(operationName = "SyncFolderItems")
    public void syncFolderItems(
        @WebParam(partName = "request", name = "SyncFolderItems",
targetNamespace =
"http://schemas.microsoft.com/exchange/services/2006/messages";)
        SyncFolderItemsType request,
"http://schemas.microsoft.com/exchange/services/2006/messages";)
        javax.xml.ws.Holder<SyncFolderItemsResponseType>
syncFolderItemsResult,
        @WebParam(partName = "ServerVersion", mode = WebParam.Mode.OUT,
name = "ServerVersionInfo", targetNamespace =
"http://schemas.microsoft.com/exchange/services/2006/types";)
 
javax.xml.ws.Holder<types._2006.services.exchange.com.microsoft.schemas.
ServerVersionInfo> serverVersion
    );

So, as you can see this method has two output parameters. I am
particularly interested in just one of them, the first one:
SyncFolderItemsResponseType. 

While debugging, I could see the response data back from the server. But
the issue is that the result data somehow gets filled at the  index=2 of
the inObjects(MessageContentsList) inside HolderInInterceptor. And then
the ClientProxy class just returns the zeroth index(which has null) from
this object. So, my holders ends up not getting filled up.

I have injected my own interceptor just after HolderInInterceptor which
does something like this:

    Object[] result = new Object[2];    
    MessageContentsList inObjects =
MessageContentsList.getContentsList(message_);
    Holder<FindItemResponseType> findItemResponseType =
(Holder<FindItemResponseType>)inObjects.get(2);
    result[0] = (Object)findItemResponseType; 
    result[1] = (Object)(new Holder<ServerVersionInfo>() );
    inObjects.set( 0, result );

Now, the holder I am interested in gets filled up with the correct
result data.

I guess what I have done is some sort of a workaround and I am not able
to address the real cause of the messed up response. It would be of
great help if you can tell me what is going wrong here.

Thanks,
Taru

Taru Bazaj
Morgan Stanley | Technology
[EMAIL PROTECTED]

-----Original Message-----
From: Daniel Kulp [mailto:[EMAIL PROTECTED] 
Sent: 15 October 2008 00:52
To: [email protected]
Cc: Bazaj, Taru (IT)
Subject: Re: CXF Generating Incorrect Namespaces in the Soap Requests

On Friday 10 October 2008 2:03:56 pm Bazaj, Taru (IT) wrote:
> Hi Dan,
>
> I tried debugging and verified that HolderOutInterceptor is getting 
> called. But it is setting the value of holders as null.
>
> Inside HolderOutInterceptor, the code is as follows:
>
> if (o instanceof Holder) {
>                     outObjects.set(x, ((Holder)o).value);
>                 } else {
>                     holders.set(x, null);
>                 }
>
> In my code sample, 'o' is an instance of SyncFolderItemsType which 
> somehow fails to be an instance of Holder. Therefore, else statement 
> gets executed and holder is set to null.

That's correct.   If it's not an "in/out" or "out" parameter, it won't
be a 
Holder and thus shouldn't be in the holders array.    Does your method
have 
any Holders?

Is there anyway you can send the WSDL for this method?   

It LOOKS like the wsdl or something is saying there are output
parameters (other than the return), but they aren't lined up as
parameters on the method 
correctly.   Not sure what would cause that.

Dan


>
> Any idea what can I do? Is there any specific annotation I need to set

> up on the SyncFolderItemsType class?
>
> Thanks a lot,
> Taru
>
> Taru Bazaj
> Morgan Stanley | Technology
> [EMAIL PROTECTED]
>
> -----Original Message-----
> From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> Sent: 09 October 2008 02:42
> To: [email protected]
> Subject: Re: CXF Generating Incorrect Namespaces in the Soap Requests
>
>
> Questions:
>
> Can you debug the sending side to see if the HolderOutInterceptor is 
> being called?  That SHOULD be setting the CLIENT_HOLDERS object.
>
> Dan
>
> On Wednesday 08 October 2008 2:58:28 pm Bazaj, Taru (IT) wrote:
> > Hi Daniel,
> >
> > I see what you mean. I was using a different factory bean which was 
> > not reading from the annotations. Now, I shifted  to using 
> > JaxWsProxyFactoryBean class and its working. Thanks a lot!
> >
> > However, now there is a new problem. When I run under the debug 
> > mode, I can see the correct response present in the message, which I

> > am receiving from the server. But somehow in the interceptor 
> > 'HolderInInterceptor' its throwing up nullPointerException. What is 
> > happening inside this interceptor is that its trying to read
> >
> > List<Holder> outHolders = CastUtils.cast((List)message.getExchange()
> >                 .getOutMessage().get(CLIENT_HOLDERS));
> >             for (MessagePartInfo part : parts) {
> >                 if (part.getIndex() != 0 && part.getTypeClass() !=
> > null) {
> >                     Holder holder =
> > (Holder)outHolders.get(part.getIndex() - 1);
> >                     holder.value = inObjects.get(part);
> >                     inObjects.put(part, holder);
> >                 }
> >
> > 'outHolders' is getting assigned a null value. I don't know how to 
> > get
> >
> > rid of this error.
> >
> > Any help will be great!
> >
> > Thanks,
> > Taru Bazaj
> > Morgan Stanley | Technology
> > [EMAIL PROTECTED]
> >
> > -----Original Message-----
> > From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> > Sent: 08 October 2008 22:35
> > To: [email protected]
> > Cc: Bazaj, Taru (IT)
> > Subject: Re: CXF Generating Incorrect Namespaces in the Soap 
> > Requests
> >
> >
> > Taru,
> >
> > How are you creating the client?   Are you using the generated
Service
> > objects or a factory bean?  If a factory, which one?
> >
> > Dan
> >
> > On Wednesday 08 October 2008, Bazaj, Taru (IT) wrote:
> > > Hi,
> > >
> > > I have a web service in .asmx. I have created a java client to 
> > > talk to
> > >
> > > this service using cxf from the wsdl exposed by the .net service.
> > >
> > > The isssue I am facing is that in the soap request the java client

> > > generates, the namespaces are incorrect. I have used the 
> > > annotation @WebService(targetNamespace = 
> > > http://schemas.microsoft.com/exchange/services/2006/messages
> > > <http://schemas.microsoft.com/exchange/services/2006/messages> ) 
> > > to set the correct namespace but still some how this is not 
> > > getting picked while generating the SOAP request. Instead, it 
> > > picks up the name of the package of the class in the reverse 
> > > order. Like the package name is 
> > > "messages._2006.services.exchange.com.microsoft.schemas" so the 
> > > namespace which gets included in the SOAP request is 
> > > "http://schemas.microsoft.com.exchange.services._2006.messages/";
> > >
> > > If anyone has faced a similar issue or can think of anything to 
> > > solve this problem please get back to me.
> > >
> > > Any help is much appreciated.
> > >
> > > Thanks,
> > > Taru Bazaj
> > > Morgan Stanley | Technology
> > > [EMAIL PROTECTED]
> > > --------------------------------------------------------
> > >
> > > NOTICE: If received in error, please destroy and notify sender.
> > > Sender
> > >
> > > does not intend to waive confidentiality or privilege. Use of this

> > > email is prohibited when received in error.
> >
> > --
> > J. Daniel Kulp
> > [EMAIL PROTECTED]
> > http://www.dankulp.com/blog
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender. 
> > Sender
> >
> > does not intend to waive confidentiality or privilege. Use of this 
> > email is prohibited when received in error.
>
> --
> Daniel Kulp
> [EMAIL PROTECTED]
> http://dankulp.com/blog
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender

> does not intend to waive confidentiality or privilege. Use of this 
> email is prohibited when received in error.



--
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

Reply via email to