I'm definitely going to need a test case from you. I've checked the system tests that we currently have and they are all using the default unqualified schemas. In particular, I looked at the CustomException.java thing that we throw (code at:
http://svn.apache.org/repos/asf/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxws/CustomException.java and the Schema it generates is definitely unqualified and the exception test does work. (Line 360 of ClientServerMiscTest.java) Could you please send me the exception class you are trying to throw so I can try and reproduce it? Thanks! Dan On Friday 11 January 2008, Daniel Kulp wrote: > 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-para > >m- 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%22unqual > > >if > > > ied%22-elementFormDefault%3D%22unqualified%22-td13604195.html#a136 > > >209 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
