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