On Thursday 01 April 2010 10:01:35 am Vanore, Gregory wrote: > Dan, > > I successfully used this technique to patch my stubs. Thanks! I do > have a remaining question: > > Is there a "best practice" here? Is calling XxxFault(..., > xxxFaultInstance) the way things are supposed to be done? I'm just > trying to understand the etiology of my issue.\
Well, that really is the JAX-WS standard way, yes. The reference impl doesn't even generate the constructors that don't take the fault bean. That said, I think it makes sense for us to change the constructors that don't take the bean to create a default bean. It MIGHT be a bit tricky though as we'd have to check if the bean is abstract or not. Not sure if that info is available within the velocity template or not. If not, it's definitely a bit more digging. Dan > > Greg > > -----Original Message----- > From: Daniel Kulp [mailto:dk...@apache.org] > Sent: Wednesday, March 31, 2010 11:28 PM > To: users@cxf.apache.org > Cc: Vanore, Gregory > Subject: Re: Losing fault type in CXF 2.2.3+ > > > > There really isn't anything like xjc plugins that can can control the > Fault > generation stuff as it's not a JAXB generated thing, that's done by us > using > velocity. You MAY be able to create a new velocity template in a jar of > path: > > org/apache/cxf/tools/wsdlto/frontend/jaxws/template/fault.vm > > and stick that jar in front of the CXF jars to pick up your template > instead. > Ours is at: > > http://svn.apache.org/repos/asf/cxf/trunk/tools/wsdlto/frontend/jaxws/sr > c/main/java/org/apache/cxf/tools/wsdlto/frontend/jaxws/template/fault.vm > > Dan > > On Wednesday 31 March 2010 10:12:39 am Vanore, Gregory wrote: > > I am migrating from CXF 2.2.2 to the latest, and my functional tests > > that cover fault conditions are failing. So, when using CXF 2.2.2, my > > fault looks normal: > > > > <soap:Envelope xmlns:soap="..."><soap:Body><soap:Fault> > > > > <faultcode>soap:Server</faultcode> > > <faultstring>...</faultstring> > > <detail><ns6:CustomFault xmlns:ns6="..."/></detail> > > > > </soap:Fault></soap:Body></soap:Envelope> > > > > Starting at CXF 2.2.3 (I tried every version between 2.2.2 and 2.2.7), > > the fault looks like this instead: > > > > <soap:Envelope xmlns:soap="..."><soap:Body><soap:Fault> > > > > <faultcode>soap:Server</faultcode> > > <faultstring>...</faultstring> > > > > </soap:Fault></soap:Body></soap:Envelope> > > > > A few points. > > > > * When I override CXF 2.2.2 to use JAXB 2.1.12, I get an empty > > <detail> > > > element. > > * If I pass a non-null fault type to my @WebFault, I can solve the > > problem, like so: > > > > throw new CustomFault("...", new CustomFaultType()); > > > > I would prefer to find a solution where I don't have to modify my code > > base to add the empty fault type bean. All WebFault types are > > generated > > > with a getFaultInfo() method. It would be nice to be able to set the > > private fault type member by default, rather than leaving it null. > > Perhaps there's some wsdltojava or xjc mojo I can leverage for this. > > > > I don't know if the change is in CXF or its supporting toolset. If > > this > > > is a change in CXF, I would recommend /at least/ inspecting the type > > of > > > the fault in the WebFault and passing that along, so that this > > information isn't lost. > > > > Or perhaps new CustomFault(String) was never right and always > > dangerous, > > > and now the bug that allowed me to exercise that path has been fixed. > > > > In any case, I would like to hear if anyone has experience with this > > or > > > recommendations on the best way to proceed. > > > > Thanks! -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
