Dan, I am wondering how you got the test case for exception to work if the SOAP messages are qualified but WSDL is unqualified. I believe that was the problem with my case also and the exception test case failed.
FYI, I am still working on 2.0.3. Are you running these test cases for exception on 2.0.3 or 2.0.4 snapshot? I noticed that in <runDocLitTest> you have a catch statement for CustomException. In my case its always something like CustomException_Exception because WSDL2Java generates this wrapper. Does 2.0.4 get rid off the wrapper exception class? I am going to give 2.0.4 a try today in the evening. Also, is the tentative release date around mid Jan? - Kannan dkulp wrote: > > > > Maybe not. I did wireshark wiretraces on the messages and the messages > are in qualified form despite the schema saying they should be > unqualified. That's definitely a bug and may be part of the issue. :-( > > I'll try and get that fixed and see if that helps. Might not be able to > get to it till monday though. Silly meetings. > > Dan > > > > On Friday 11 January 2008, Daniel Kulp wrote: >> 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-pa >> > >ra 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%22unqu >> > > >al if >> > > > ied%22-elementFormDefault%3D%22unqualified%22-td13604195.html#a1 >> > > >36 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 > -- View this message in context: http://www.nabble.com/Exception-object-has-all-fields-set-to-NULL-on-client-side-tp14723440p14764053.html Sent from the cxf-user mailing list archive at Nabble.com.
