You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2007/11/30 23:21:41 UTC

Re: Non-compliant Java exception class generation? (Was Re: Custom exceptions in CXF web-service)

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_12537610



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

Re: Non-compliant Java exception class generation? (Was Re: Custom exceptions in CXF web-service)

Posted by Daniel Kulp <dk...@apache.org>.
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

Re: Non-compliant Java exception class generation? (Was Re: Custom exceptions in CXF web-service)

Posted by Glen Mazza <gl...@verizon.net>.
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?

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