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/src/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 [email protected] http://dankulp.com/blog
