Dan, I followed the discussion on CXF-1226 in this forum and found it very helpful. (http://www.nabble.com/Created:-(CXF-1226)-Missing-input-output-param-namespace-in-SOAP-td13870857.html)
The workaround proposed by Benson is creating a qualified schema and fixing the NULL field problem. I tried the ReflectionServiceFactoryBean approach that you had suggested but I couldn't get it working. You had mentioned that it was not very well tested at that time. It will be cleaner to use a spring configuration rather than create package-info files and dummy beans. Do have any update on its status? - Kannan rkannan wrote: > > 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-tp14723440p14753150.html Sent from the cxf-user mailing list archive at Nabble.com.
