You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Vanore, Gregory" <Gr...@solers.com> on 2010/03/31 16:12:39 UTC
Losing fault type in CXF 2.2.3+
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!
Re: Losing fault type in CXF 2.2.3+
Posted by Daniel Kulp <dk...@apache.org>.
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:dkulp@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
dkulp@apache.org
http://dankulp.com/blog
RE: Losing fault type in CXF 2.2.3+
Posted by "Vanore, Gregory" <Gr...@solers.com>.
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.
Greg
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@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
dkulp@apache.org
http://dankulp.com/blog
Re: Losing fault type in CXF 2.2.3+
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://dankulp.com/blog