cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Non-compliant Java exception class generation? (Was Re: Custom exceptions in CXF web-service)
Date Fri, 30 Nov 2007 23:28:15 GMT
On Friday 30 November 2007, Glen Mazza wrote:
> I'm not sure what you mean by "handle"--Was the top constructor
> removed from JAX-WS generation--if not, why do we still have it, what
> was the reason for moving beyond the spec to include it?

By handle, I mean it will "properly" get deserialized back into the 
appropriate exception on the client side and thrown.   Basically, if the 
details are "xsi:nil" on the wire, it will not "blow up".

The main reason for including it is that it's what most java developers 
expect.   It's a convienience.   The spec mandates the other two 
constructors, but it doesn't EXCLUDE additional constructors.   If you 
use them, you're out of the portability guarantees of the the JAX-WS 
spec, but they are nice to have.  

I think we generate a couple extra constructors on the client side 
Service objects as well for the same reason.

Dan



>
> Thanks,
> Glen
>
> Am Freitag, den 30.11.2007, 17:21 -0500 schrieb Daniel Kulp:
> > Glen,
> >
> > I think for 2.0.3, I fixed the reader/writer to hande the top
> > constructor and null details.   See:
> > https://issues.apache.org/jira/browse/CXF-1131
> >
> > Dan
> >
> > On Thursday 29 November 2007, Glen Mazza wrote:
> > > Team,
> > >
> > > If you look at [2] below, we are providing three constructors when
> > > we generate a Java exception class for a wsdl:fault element.
> > >
> > > However, the May 2007 JAX-WS 2.1 spec, bottom of page 22 and top
> > > of page 23, states that we should only be providing the bottom two
> > > constructors. Also, as [2] notes, Metro only provides those two
> > > constructors.
> > >
> > > The problem with the top constructor is the FaultBean, or custom
> > > exception, is not getting stored when you use it, causing the
> > > reader below (and the reader who had the bug at [1]) to be losing
> > > the custom exception and instead just getting a basic
> > > SOAPFaultException.  Also, it makes service code non-portable
> > > between Metro and CXF.
> > >
> > > I think we should stop supplying the top, one-parameter
> > > constructor from the list below.  (Deprecate it if necessary?)  It
> > > keeps us compliant with the spec and also prevents users from
> > > falling into the "Where's my custom exception?" trap below.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > Glen
> > >
> > > Am Donnerstag, den 29.11.2007, 05:22 -0500 schrieb Glen Mazza:
> > > > Upgrade to the two or three parameter one, as you can see from
> > > > [2], they are the only versions that will incorporate your
> > > > custom exception:
> > > >
> > > > (Code from [2]:)
> > > >
> > > > // ignores custom exception:
> > > > public CustomException (String message) { super(message); }
> > > >
> > > > // absorbs custom exception:
> > > > public CustomException (String message,
> > > > demo.hw.company.CustomExceptionType customException) {
> > > >  super(message); -->this.customException = customException;<-- }
> > > >
> > > > // absorbs custom exception:
> > > > public CustomException (String message,
> > > > demo.hw.company.CustomExceptionType customException, Throwable
> > > > cause) { super(message, cause); -->this.customException =
> > > > customException;<-- }
> > > >
> > > > Am Donnerstag, den 29.11.2007, 01:45 -0800 schrieb imorales:
> > > > > I use the one parameter Constructor.
> > > > > --> throw new MetaInformacionException("Error in meta Info")
> > > > >
> > > > > Glen Mazza-2 wrote:
> > > > > > Am Mittwoch, den 28.11.2007, 00:25 -0800 schrieb imorales:
> > > > > >> Hi all. I developed a web service using CXF. The methods
of
> > > > > >> the web service
> > > > > >> throws Custom Exceptions. Something like that:
> > > > > >>
> > > > > >> -----------------------------------------------------------
> > > > > >>---- -------------------------- @WebResult(name="ticket")
> > > > > >> Long iniciaFormulario( @WebParam(name="xslt") String xslt)
> > > > > >> throws MetaInformacionException;
> > > > > >> -----------------------------------------------------------
> > > > > >>---- --------------------------
> > > > > >>
> > > > > >> And MetaInformacionException extends of Exception.
> > > > > >>
> > > > > >> The problem is that when in my server throw a new
> > > > > >> MetaInformacionException
> > > > > >> the client never catch the exception because the excepction
> > > > > >> that occurs is a
> > > > > >> "javax.xml.rpc.soap.SOAPFaultException" but with the
> > > > > >> message of my custom Exception.
> > > > > >
> > > > > > I was able to get custom exceptions to work using a
> > > > > > WSDL-first approach[1].  From the web service, when you
> > > > > > construct your "new MetaInformationException", make sure you
> > > > > > are not using the no-parameter constructor version (in my
> > > > > > example[1], I use a two-parameter constructor.)  That
> > > > > > *might* be the problem you are having, someone else had a
> > > > > > similar issue[2].
> > > > > >
> > > > > > HTH,
> > > > > > Glen
> > > > > >
> > > > > > [1] http://www.jroller.com/gmazza/date/20071019#step6
> > > > > > [2]
> > > > > > http://issues.apache.org/jira/browse/CXF-1136#action_1253761
> > > > > >0



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Mime
View raw message