Return-Path: 
 <cxf-user-return-5333-apmail-incubator-cxf-user-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-cxf-user-archive@locus.apache.org
Received: (qmail 25955 invoked from network); 14 Jan 2008 16:06:20 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 14 Jan 2008 16:06:20 -0000
Received: (qmail 52591 invoked by uid 500); 14 Jan 2008 16:06:07 -0000
Delivered-To: apmail-incubator-cxf-user-archive@incubator.apache.org
Received: (qmail 52548 invoked by uid 500); 14 Jan 2008 16:06:07 -0000
Mailing-List: contact cxf-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:cxf-user-help@incubator.apache.org>
List-Unsubscribe: <mailto:cxf-user-unsubscribe@incubator.apache.org>
List-Post: <mailto:cxf-user@incubator.apache.org>
List-Id: <cxf-user.incubator.apache.org>
Reply-To: cxf-user@incubator.apache.org
Delivered-To: mailing list cxf-user@incubator.apache.org
Received: (qmail 52539 invoked by uid 99); 14 Jan 2008 16:06:07 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Jan 2008 08:06:07 -0800
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=SPF_HELO_PASS,SPF_NEUTRAL,WHOIS_MYPRIVREG
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [64.79.194.121] (HELO mesa2.com) (64.79.194.121)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Jan 2008 16:05:40 +0000
Received: from [24.147.10.180] (account jdkulp HELO
 dilbert.boston.amer.iona.com)
  by mesa2.com (CommuniGate Pro SMTP 4.1.8)
  with ESMTP id 1751945; Mon, 14 Jan 2008 11:05:44 -0500
From: Daniel Kulp <dkulp@apache.org>
To: cxf-user@incubator.apache.org
Subject: Re: Exception object has all fields set to NULL on client side
Date: Mon, 14 Jan 2008 11:05:43 -0500
User-Agent: KMail/1.9.7
Cc: rkannan <rkannan_82@yahoo.com>
References: <14723440.post@talk.nabble.com>
 <200801111027.42302.dkulp@apache.org> <14764053.post@talk.nabble.com>
In-Reply-To: <14764053.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200801141105.44081.dkulp@apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

On Friday 11 January 2008, rkannan wrote:
> 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.

The test case is java first on both client and server.    Thus, there is 
no wsdl -> java run to generate the JAXWS/JAXB version of the 
exceptions.    That's actually why it works.   The server is writing the 
exception wrong, but the java first code for reading the exception is 
based on the same assumptions so it reads it fine.   

> 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?

No.   It's using the exact same exception class as the server side.   
This is a PURE java first test.    No wsdl or code generation involved 
at all.

> I am going to give 2.0.4 a try today in the evening. Also, is the
> tentative release date around mid Jan?

Yep.   I was hoping for early this week, but we still have several open 
issues we need to look at.   Thus, hopefully late this week or early 
next week.

Dan


>
> - 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/te
> >>st/ 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%22u
> >> > > >nqu 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
> >> > > >> dkulp@apache.org
> >> > > >> http://www.dankulp.com/blog
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer, IONA
> > dkulp@apache.org
> > http://www.dankulp.com/blog



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog