Dan,
  Sorry, I made a mistake in my previous post. There is nothing wrong with
parsing the SOAP detail. However the problem is with the Unmarshaller piece.
As you said I wrote a simple HelloWorld program that throws an exception and
this is what I found out. 

- HelloWorld program is working fine for exception. The reason is that the
generated WSDL has elementFormDefault=qualified on its schema. As a result,
WSDL2Java generates stub code that has @XmlElement annotation with namespace
attribute on the protected field of exception class. I checked to see what
happens when elementFormDefault is set to unqualified in WSDL. The generated
stub code does not have namespace atttribute in @XmElement annotation. In
this case the fields of exception object are all null (my original post
talks about this problem). I believe while unmarshalling the fault message,
the namespace attribute in SOAP fault message is compared with the
annotation and it fails here. When you said its working fine with your
sample program, I assume its because of qualified schema. Can you check if
it works fine with unqualified also?

- Having figured this, I decided to generate the WSDL of my original problem
with elementFormDefault set to qualified. I followed the instruction in this
post:
http://www.nabble.com/xs%3Aschema-attributeFormDefault%3D%22unqualified%22-elementFormDefault%3D%22unqualified%22-td13604195.html#a13620904
But I am not able to get it to work. There is no change in the WSDL. 

What is the correct way to get this problem resolved? Using <qualified> in
WSDL (if so how?), or is there a bug. Because even with unqualified schema,
unmarhsalling happens fine for SOAP request/response messages other than
fault messages. 

Thanks,
Kannan


dkulp wrote:
> 
> 
> Kannan,
> 
> Any chance you could come up with an example so I can see what the issue 
> is in a debugger?   A modified hello world or something would be great.   
> The samples that I've written seem to be OK.
> 
> Dan
> 
> 
> On Thursday 10 January 2008, rkannan wrote:
>> I did some debugging of the CXF code and figured the following: There
>> is a call to a method in StaxUtils that parses the SOAP fault
>> response. It correctly identifies values for all headers except
>> <detail>. As a result a NULL value is returned for fault detail; the
>> created exception object therefore has its member variables
>> uninitialized. This could be a bug in CXF. Maybe we need to include
>> some jar file that has correct implementation for parsing the SOAP
>> fault. This is a serious block.
>>
>> - Kannan
>>
>> rkannan wrote:
>> > I am throwing an exception from server side but on the client side
>> > the exception object has all the fields set to NULL. I checked the
>> > incoming SOAP fault message and it has correct values for the
>> > fields. I believe the correct jar files are not being used because I
>> > had a similar problem in sending List data types as parameters and
>> > it was fixed by adding asm.jar. I am using Wrapped Doc/Lit with the
>> > following dependencies on client:
>> >
>> > --------------------------------------------------------------------
>> >------------------------------ <dependency>
>> >             <groupId>junit</groupId>
>> >             <artifactId>junit</artifactId>
>> >             <version>4.1</version>
>> >             <scope>provided</scope>
>> >         </dependency>
>> >
>> >     <dependency>
>> >             <groupId>org.apache.cxf</groupId>
>> >             <artifactId>cxf-rt-frontend-jaxws</artifactId>
>> >             <version>${cxf.version}</version>
>> >         </dependency>
>> >
>> >
>> >    <dependency>
>> >             <groupId>org.apache.cxf</groupId>
>> >             <artifactId>cxf-rt-transports-http</artifactId>
>> >             <version>${cxf.version}</version>
>> >         </dependency>
>> >
>> >    <dependency>
>> >             <groupId>asm</groupId>
>> >             <artifactId>asm</artifactId>
>> >             <version>3.0</version>
>> >         </dependency>
>> > --------------------------------------------------------------------
>> >------------------------------
>> >
>> > If it really is a problem with using the correct jar files, it will
>> > be very helpful to get a list of jars that need to be used on server
>> > and client side to enable web service using CXF. I read the
>> > <WHICH_JARS> file that is part of CXF download, but adding them has
>> > not solved my problem. Can someone point out which classes are
>> > absolutely needed to handle fault/exception objects properly?
>> >
>> > Thanks,
>> > Kannan
> 
> 
> 
> -- 
> J. Daniel Kulp
> Principal Engineer, IONA
> [EMAIL PROTECTED]
> http://www.dankulp.com/blog
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Exception-object-has-all-fields-set-to-NULL-on-client-side-tp14723440p14749557.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to