The stuff in CXF-1226 is new for 2.0.4 so you would need to be using a snapshot version of 2.0.4 for that to work. I'm looking into the other stuff now.
Dan On Friday 11 January 2008, rkannan wrote: > 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%22unqualif > >ied%22-elementFormDefault%3D%22unqualified%22-td13604195.html#a136209 > >04 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 -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
