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 [EMAIL PROTECTED] http://www.dankulp.com/blog
