You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Benson Margulies <bi...@basistech.com> on 2007/10/19 02:25:37 UTC
JAXB + JAX-WS + faults
Since moving to the latest 2.0.3 snapshot, I'm getting an exception when
marshalling a fault declared on a 'throws' clause. No @WebFault. This
didn't happen with 2.0.2 afaik.
WARNING: Exception occurred while writing fault.
org.apache.cxf.interceptor.Fault: Marshalling Error:
com.basistech.ws.fortest.TestException is not known to this context
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:
179)
at
org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:42)
at
org.apache.cxf.interceptor.FaultOutInterceptor.handleMessage(FaultOutInt
erceptor.java:75)
at
org.apache.cxf.jaxws.interceptors.WebFaultOutInterceptor.handleMessage(W
ebFaultOutInterceptor.java:127)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:207)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage
(AbstractFaultChainInitiatorObserver.java:90)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:224)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiati
onObserver.java:73)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(
JettyHTTPDestination.java:282)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(Jetty
HTTPDestination.java:238)
at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHan
dler.java:54)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandler
Collection.java:211)
at
org.mortbay.jetty.handler.HandlerList.handle(HandlerList.java:49)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.j
ava:844)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
396)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.ja
va:442)
Caused by: javax.xml.bind.MarshalException
- with linked exception:
[javax.xml.bind.JAXBException: com.basistech.ws.fortest.TestException is
not known to this context]
at
com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:295
)
at
com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:2
21)
at
javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshaller
Impl.java:91)
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.ja
va:192)
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:
167)
... 22 more
Caused by: javax.xml.bind.JAXBException:
com.basistech.ws.fortest.TestException is not known to this context
at
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java
:223)
at
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java
:238)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementB
eanInfoImpl.java:85)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementB
eanInfoImpl.java:127)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBea
nInfoImpl.java:244)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBea
nInfoImpl.java:251)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBea
nInfoImpl.java:33)
at
com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java
:461)
at
com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292
)
... 26 more
Caused by: javax.xml.bind.JAXBException:
com.basistech.ws.fortest.TestException is not known to this context
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.
java:538)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementB
eanInfoImpl.java:82)
... 32 more
Oct 18, 2007 8:22:55 PM
org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
RE: JAXB + JAX-WS + faults
Posted by Benson Margulies <bi...@basistech.com>.
A principle of mine: there should be some way for the programmer to
indicate that they accept and understand this behavior, and that should
banish the message.
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, October 19, 2007 2:12 PM
> To: cxf-user@incubator.apache.org
> Cc: Benson Margulies
> Subject: Re: JAXB + JAX-WS + faults
>
>
> Well, the issue is that the system is "working as designed", however,
it
> may not be working as the user THINKS it is designed.
>
> For example, if I create an exception like:
>
> public class FooException extends Exception {
> String user, group;
> public FooException(String msg, String user, String group) {
> super(msg);
> this.user = user;
> this.group = group;
> }
> .... getter/setters for group/user ....
> }
> and throw that, I MAY expect the user and group to be added to the
> details of the fault and then mapped into a FooException on the client
> side. However, that won't happen with JAXB because it doesn't have
a
> default constructor so it would never be added to the context.
Logging
> at FINE basically would never tell me that the databinding couldn't
> handle it.
>
> That's pretty much why I made it log at WARNING. It falls into the
"we
> do have a default behavior to handle this, but it's probably not what
> you want" realm of things that I do like to let the user know about.
>
>
> Dan
>
> On Friday 19 October 2007, Benson Margulies wrote:
> > I'd vote for FINE. The system is 'working as designed'.
> >
> > If we push it to FINE, I'd not bother to keep track.
> >
> > > -----Original Message-----
> > > From: Daniel Kulp [mailto:dkulp@apache.org]
> > > Sent: Friday, October 19, 2007 1:13 PM
> > > To: cxf-user@incubator.apache.org
> > > Cc: Benson Margulies
> > > Subject: Re: JAXB + JAX-WS + faults
> > >
> > > On Friday 19 October 2007, Benson Margulies wrote:
> > > > Should we reduce the logging noisiness of this process?
> > >
> > > That's a good question. I can definitely see taking the stack
trace
> >
> > off
> >
> > > of it. That's just scary to users. I'd probably change the
> > > message to:
> > >
> > > Exception occurred while writing user fault. {0} Delegating to
> >
> > binding
> >
> > > fault writing routines.
> > >
> > > Next question: what log level? FINE, INFO, WARNING?
> > >
> > > Next: should we keep track of the classes that we couldn't write
and
> >
> > just
> >
> > > log on the FIRST time that type is encountered?
> > >
> > >
> > > Thoughts?
> > > Dan
> > >
> > > > > -----Original Message-----
> > > > > From: Daniel Kulp [mailto:dkulp@apache.org]
> > > > > Sent: Friday, October 19, 2007 1:01 PM
> > > > > To: cxf-user@incubator.apache.org
> > > > > Cc: Benson Margulies
> > > > > Subject: Re: JAXB + JAX-WS + faults
> > > > >
> > > > >
> > > > > Benson,
> > > > >
> > > > > This is a sideaffect of the fixes we did for the Aegis faults
> > > > > with the JAX-WS frontend. By making the
WebFaultOutInterceptor
> >
> > delegate
> >
> > > > > up to the normal fault handling, the databinding gets a crack
at
> > > > > trying to write the fault.
> > > > >
> > > > > In 2.0.2, if the exception didn't have an @WebFault, the
> > > > > WebFaultOutInterceptor would ignore it and then the
SOAPFaultOut
> > > > > stuff would then just map the getMessage() call onto the wire
an
> >
> > no
> >
> > > > > other
> > > >
> > > > data
> > > >
> > > > > would get sent on the wire.
> > > > >
> > > > > With 2.0.3, the superclass gets a chance which basically feeds
> > > > > the
> > > >
> > > > fault
> > > >
> > > > > into the databinding writer. In this case, JAXB doesn't know
> > > > > what to
> > > >
> > > > do
> > > >
> > > > > with it and throws an exception. The FaultOutInterceptor
does
> > > >
> > > > swallow
> > > >
> > > > > that exception so it does properly go to the SOAPFaultOut
stuff
> > > > > as before, but I did log it so you know any detail that may be
> > > > > in the Exception that you expected to be on the wire won't be
> > > > > there.
> >
> > The
> >
> > > > > databinding had no clue what to do with it.
> > > > >
> > > > >
> > > > > Dan
> > > > >
> > > > > On Thursday 18 October 2007, Benson Margulies wrote:
> > > > > > Since moving to the latest 2.0.3 snapshot, I'm getting an
> > > > > > exception when marshalling a fault declared on a 'throws'
> >
> > clause.
> >
> > > > > > No
> > > >
> > > > @WebFault.
> > > >
> > > > > > This didn't happen with 2.0.2 afaik.
> > > > > >
> > > > > > WARNING: Exception occurred while writing fault.
> > > > > > org.apache.cxf.interceptor.Fault: Marshalling Error:
> > > > > > com.basistech.ws.fortest.TestException is not known to this
> > > > > > context at
> >
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
Re: JAXB + JAX-WS + faults
Posted by Daniel Kulp <dk...@apache.org>.
Well, the issue is that the system is "working as designed", however, it
may not be working as the user THINKS it is designed.
For example, if I create an exception like:
public class FooException extends Exception {
String user, group;
public FooException(String msg, String user, String group) {
super(msg);
this.user = user;
this.group = group;
}
.... getter/setters for group/user ....
}
and throw that, I MAY expect the user and group to be added to the
details of the fault and then mapped into a FooException on the client
side. However, that won't happen with JAXB because it doesn't have a
default constructor so it would never be added to the context. Logging
at FINE basically would never tell me that the databinding couldn't
handle it.
That's pretty much why I made it log at WARNING. It falls into the "we
do have a default behavior to handle this, but it's probably not what
you want" realm of things that I do like to let the user know about.
Dan
On Friday 19 October 2007, Benson Margulies wrote:
> I'd vote for FINE. The system is 'working as designed'.
>
> If we push it to FINE, I'd not bother to keep track.
>
> > -----Original Message-----
> > From: Daniel Kulp [mailto:dkulp@apache.org]
> > Sent: Friday, October 19, 2007 1:13 PM
> > To: cxf-user@incubator.apache.org
> > Cc: Benson Margulies
> > Subject: Re: JAXB + JAX-WS + faults
> >
> > On Friday 19 October 2007, Benson Margulies wrote:
> > > Should we reduce the logging noisiness of this process?
> >
> > That's a good question. I can definitely see taking the stack trace
>
> off
>
> > of it. That's just scary to users. I'd probably change the
> > message to:
> >
> > Exception occurred while writing user fault. {0} Delegating to
>
> binding
>
> > fault writing routines.
> >
> > Next question: what log level? FINE, INFO, WARNING?
> >
> > Next: should we keep track of the classes that we couldn't write and
>
> just
>
> > log on the FIRST time that type is encountered?
> >
> >
> > Thoughts?
> > Dan
> >
> > > > -----Original Message-----
> > > > From: Daniel Kulp [mailto:dkulp@apache.org]
> > > > Sent: Friday, October 19, 2007 1:01 PM
> > > > To: cxf-user@incubator.apache.org
> > > > Cc: Benson Margulies
> > > > Subject: Re: JAXB + JAX-WS + faults
> > > >
> > > >
> > > > Benson,
> > > >
> > > > This is a sideaffect of the fixes we did for the Aegis faults
> > > > with the JAX-WS frontend. By making the WebFaultOutInterceptor
>
> delegate
>
> > > > up to the normal fault handling, the databinding gets a crack at
> > > > trying to write the fault.
> > > >
> > > > In 2.0.2, if the exception didn't have an @WebFault, the
> > > > WebFaultOutInterceptor would ignore it and then the SOAPFaultOut
> > > > stuff would then just map the getMessage() call onto the wire an
>
> no
>
> > > > other
> > >
> > > data
> > >
> > > > would get sent on the wire.
> > > >
> > > > With 2.0.3, the superclass gets a chance which basically feeds
> > > > the
> > >
> > > fault
> > >
> > > > into the databinding writer. In this case, JAXB doesn't know
> > > > what to
> > >
> > > do
> > >
> > > > with it and throws an exception. The FaultOutInterceptor does
> > >
> > > swallow
> > >
> > > > that exception so it does properly go to the SOAPFaultOut stuff
> > > > as before, but I did log it so you know any detail that may be
> > > > in the Exception that you expected to be on the wire won't be
> > > > there.
>
> The
>
> > > > databinding had no clue what to do with it.
> > > >
> > > >
> > > > Dan
> > > >
> > > > On Thursday 18 October 2007, Benson Margulies wrote:
> > > > > Since moving to the latest 2.0.3 snapshot, I'm getting an
> > > > > exception when marshalling a fault declared on a 'throws'
>
> clause.
>
> > > > > No
> > >
> > > @WebFault.
> > >
> > > > > This didn't happen with 2.0.2 afaik.
> > > > >
> > > > > WARNING: Exception occurred while writing fault.
> > > > > org.apache.cxf.interceptor.Fault: Marshalling Error:
> > > > > com.basistech.ws.fortest.TestException is not known to this
> > > > > context at
>
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: JAXB + JAX-WS + faults
Posted by Benson Margulies <bi...@basistech.com>.
Dan,
It would seem that the line of least resistance is to make [] work like
List<>.
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, October 19, 2007 1:13 PM
> To: cxf-user@incubator.apache.org
> Cc: Benson Margulies
> Subject: Re: JAXB + JAX-WS + faults
>
>
> On Friday 19 October 2007, Benson Margulies wrote:
> > Should we reduce the logging noisiness of this process?
>
> That's a good question. I can definitely see taking the stack trace
off
> of it. That's just scary to users. I'd probably change the message
> to:
>
> Exception occurred while writing user fault. {0} Delegating to
binding
> fault writing routines.
>
> Next question: what log level? FINE, INFO, WARNING?
>
> Next: should we keep track of the classes that we couldn't write and
just
> log on the FIRST time that type is encountered?
>
>
> Thoughts?
> Dan
>
> >
> > > -----Original Message-----
> > > From: Daniel Kulp [mailto:dkulp@apache.org]
> > > Sent: Friday, October 19, 2007 1:01 PM
> > > To: cxf-user@incubator.apache.org
> > > Cc: Benson Margulies
> > > Subject: Re: JAXB + JAX-WS + faults
> > >
> > >
> > > Benson,
> > >
> > > This is a sideaffect of the fixes we did for the Aegis faults with
> > > the JAX-WS frontend. By making the WebFaultOutInterceptor
delegate
> > > up to the normal fault handling, the databinding gets a crack at
> > > trying to write the fault.
> > >
> > > In 2.0.2, if the exception didn't have an @WebFault, the
> > > WebFaultOutInterceptor would ignore it and then the SOAPFaultOut
> > > stuff would then just map the getMessage() call onto the wire an
no
> > > other
> >
> > data
> >
> > > would get sent on the wire.
> > >
> > > With 2.0.3, the superclass gets a chance which basically feeds the
> >
> > fault
> >
> > > into the databinding writer. In this case, JAXB doesn't know what
> > > to
> >
> > do
> >
> > > with it and throws an exception. The FaultOutInterceptor does
> >
> > swallow
> >
> > > that exception so it does properly go to the SOAPFaultOut stuff as
> > > before, but I did log it so you know any detail that may be in the
> > > Exception that you expected to be on the wire won't be there.
The
> > > databinding had no clue what to do with it.
> > >
> > >
> > > Dan
> > >
> > > On Thursday 18 October 2007, Benson Margulies wrote:
> > > > Since moving to the latest 2.0.3 snapshot, I'm getting an
> > > > exception when marshalling a fault declared on a 'throws'
clause.
> > > > No
> >
> > @WebFault.
> >
> > > > This didn't happen with 2.0.2 afaik.
> > > >
> > > > WARNING: Exception occurred while writing fault.
> > > > org.apache.cxf.interceptor.Fault: Marshalling Error:
> > > > com.basistech.ws.fortest.TestException is not known to this
> > > > context at
> >
> >
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.jav
> >
> > > >a: 179)
> > > > at
> > > >
org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:42
> > > >) at
> >
> >
org.apache.cxf.interceptor.FaultOutInterceptor.handleMessage(FaultOutI
> >
> > > >nt erceptor.java:75)
> > > > at
> >
> >
org.apache.cxf.jaxws.interceptors.WebFaultOutInterceptor.handleMessage
> >
> > > >(W ebFaultOutInterceptor.java:127)
> > > > at
> >
> >
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> >
> > > >rC hain.java:207)
> > > > at
> >
> >
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessa
> >
> > > >ge (AbstractFaultChainInitiatorObserver.java:90)
> > > > at
> >
> >
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> >
> > > >rC hain.java:224)
> > > > at
> >
> >
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
> >
> > > >ti onObserver.java:73)
> > > > at
> >
> >
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceReques
> >
> > > >t( JettyHTTPDestination.java:282)
> > > > at
> >
> >
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(Jet
> >
> > > >ty HTTPDestination.java:238)
> > > > at
> >
> >
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPH
> >
> > > >an dler.java:54)
> > > > at
> >
> >
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:71
> >
> > > >2) at
> >
> >
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandl
> >
> > > >er Collection.java:211)
> > > > at
> > > >
org.mortbay.jetty.handler.HandlerList.handle(HandlerList.java:49)
> > > > at
> >
> >
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:13
> >
> > > >9) at org.mortbay.jetty.Server.handle(Server.java:313)
> > > > at
> >
> >
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506
> >
> > > >) at
> >
> >
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection
> >
> > > >.j ava:844)
> > > > at
org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
> > > > at
> > > > org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> > > > at
> > > > org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
> > > > at
> >
> >
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.jav
> >
> > > >a: 396)
> > > > at
> >
> >
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.
> >
> > > >ja va:442)
> > > > Caused by: javax.xml.bind.MarshalException
> > > > - with linked exception:
> > > > [javax.xml.bind.JAXBException:
> >
> > com.basistech.ws.fortest.TestException
> >
> > > > is not known to this context]
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:2
> >
> > > >95 )
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java
> >
> > > >:2 21)
> > > >
> > > > at
> >
> >
javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshall
> >
> > > >er Impl.java:91)
> > > > at
> >
> >
org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.
> >
> > > >ja va:192)
> > > > at
> >
> >
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.jav
> >
> > > >a: 167)
> > > > ... 22 more
> > > > Caused by: javax.xml.bind.JAXBException:
> > > > com.basistech.ws.fortest.TestException is not known to this
> > > > context at
> >
> >
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.ja
> >
> > > >va
> > > >
> > > > :223)
> > > >
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.ja
> >
> > > >va
> > > >
> > > > :238)
> > > >
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
> >
> > > >tB eanInfoImpl.java:85)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
> >
> > > >tB eanInfoImpl.java:127)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementB
> >
> > > >ea nInfoImpl.java:244)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementB
> >
> > > >ea nInfoImpl.java:251)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementB
> >
> > > >ea nInfoImpl.java:33)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.ja
> >
> > > >va
> > > >
> > > > :461)
> > > >
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:2
> >
> > > >92 )
> > > > ... 26 more
> > > > Caused by: javax.xml.bind.JAXBException:
> > > > com.basistech.ws.fortest.TestException is not known to this
> > > > context at
> >
> >
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImp
> >
> > > >l. java:538)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
> >
> > > >tB eanInfoImpl.java:82)
> > > > ... 32 more
> > > > Oct 18, 2007 8:22:55 PM
> > > > org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback
> > > > onClose
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer
> > > IONA
> > > P: 781-902-8727 C: 508-380-7194
> > > daniel.kulp@iona.com
> > > http://www.dankulp.com/blog
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
RE: JAXB + JAX-WS + faults
Posted by Benson Margulies <bi...@basistech.com>.
I'd vote for FINE. The system is 'working as designed'.
If we push it to FINE, I'd not bother to keep track.
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, October 19, 2007 1:13 PM
> To: cxf-user@incubator.apache.org
> Cc: Benson Margulies
> Subject: Re: JAXB + JAX-WS + faults
>
>
> On Friday 19 October 2007, Benson Margulies wrote:
> > Should we reduce the logging noisiness of this process?
>
> That's a good question. I can definitely see taking the stack trace
off
> of it. That's just scary to users. I'd probably change the message
> to:
>
> Exception occurred while writing user fault. {0} Delegating to
binding
> fault writing routines.
>
> Next question: what log level? FINE, INFO, WARNING?
>
> Next: should we keep track of the classes that we couldn't write and
just
> log on the FIRST time that type is encountered?
>
>
> Thoughts?
> Dan
>
> >
> > > -----Original Message-----
> > > From: Daniel Kulp [mailto:dkulp@apache.org]
> > > Sent: Friday, October 19, 2007 1:01 PM
> > > To: cxf-user@incubator.apache.org
> > > Cc: Benson Margulies
> > > Subject: Re: JAXB + JAX-WS + faults
> > >
> > >
> > > Benson,
> > >
> > > This is a sideaffect of the fixes we did for the Aegis faults with
> > > the JAX-WS frontend. By making the WebFaultOutInterceptor
delegate
> > > up to the normal fault handling, the databinding gets a crack at
> > > trying to write the fault.
> > >
> > > In 2.0.2, if the exception didn't have an @WebFault, the
> > > WebFaultOutInterceptor would ignore it and then the SOAPFaultOut
> > > stuff would then just map the getMessage() call onto the wire an
no
> > > other
> >
> > data
> >
> > > would get sent on the wire.
> > >
> > > With 2.0.3, the superclass gets a chance which basically feeds the
> >
> > fault
> >
> > > into the databinding writer. In this case, JAXB doesn't know what
> > > to
> >
> > do
> >
> > > with it and throws an exception. The FaultOutInterceptor does
> >
> > swallow
> >
> > > that exception so it does properly go to the SOAPFaultOut stuff as
> > > before, but I did log it so you know any detail that may be in the
> > > Exception that you expected to be on the wire won't be there.
The
> > > databinding had no clue what to do with it.
> > >
> > >
> > > Dan
> > >
> > > On Thursday 18 October 2007, Benson Margulies wrote:
> > > > Since moving to the latest 2.0.3 snapshot, I'm getting an
> > > > exception when marshalling a fault declared on a 'throws'
clause.
> > > > No
> >
> > @WebFault.
> >
> > > > This didn't happen with 2.0.2 afaik.
> > > >
> > > > WARNING: Exception occurred while writing fault.
> > > > org.apache.cxf.interceptor.Fault: Marshalling Error:
> > > > com.basistech.ws.fortest.TestException is not known to this
> > > > context at
> >
> >
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.jav
> >
> > > >a: 179)
> > > > at
> > > >
org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:42
> > > >) at
> >
> >
org.apache.cxf.interceptor.FaultOutInterceptor.handleMessage(FaultOutI
> >
> > > >nt erceptor.java:75)
> > > > at
> >
> >
org.apache.cxf.jaxws.interceptors.WebFaultOutInterceptor.handleMessage
> >
> > > >(W ebFaultOutInterceptor.java:127)
> > > > at
> >
> >
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> >
> > > >rC hain.java:207)
> > > > at
> >
> >
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessa
> >
> > > >ge (AbstractFaultChainInitiatorObserver.java:90)
> > > > at
> >
> >
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> >
> > > >rC hain.java:224)
> > > > at
> >
> >
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
> >
> > > >ti onObserver.java:73)
> > > > at
> >
> >
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceReques
> >
> > > >t( JettyHTTPDestination.java:282)
> > > > at
> >
> >
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(Jet
> >
> > > >ty HTTPDestination.java:238)
> > > > at
> >
> >
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPH
> >
> > > >an dler.java:54)
> > > > at
> >
> >
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:71
> >
> > > >2) at
> >
> >
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandl
> >
> > > >er Collection.java:211)
> > > > at
> > > >
org.mortbay.jetty.handler.HandlerList.handle(HandlerList.java:49)
> > > > at
> >
> >
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:13
> >
> > > >9) at org.mortbay.jetty.Server.handle(Server.java:313)
> > > > at
> >
> >
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506
> >
> > > >) at
> >
> >
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection
> >
> > > >.j ava:844)
> > > > at
org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
> > > > at
> > > > org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> > > > at
> > > > org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
> > > > at
> >
> >
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.jav
> >
> > > >a: 396)
> > > > at
> >
> >
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.
> >
> > > >ja va:442)
> > > > Caused by: javax.xml.bind.MarshalException
> > > > - with linked exception:
> > > > [javax.xml.bind.JAXBException:
> >
> > com.basistech.ws.fortest.TestException
> >
> > > > is not known to this context]
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:2
> >
> > > >95 )
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java
> >
> > > >:2 21)
> > > >
> > > > at
> >
> >
javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshall
> >
> > > >er Impl.java:91)
> > > > at
> >
> >
org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.
> >
> > > >ja va:192)
> > > > at
> >
> >
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.jav
> >
> > > >a: 167)
> > > > ... 22 more
> > > > Caused by: javax.xml.bind.JAXBException:
> > > > com.basistech.ws.fortest.TestException is not known to this
> > > > context at
> >
> >
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.ja
> >
> > > >va
> > > >
> > > > :223)
> > > >
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.ja
> >
> > > >va
> > > >
> > > > :238)
> > > >
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
> >
> > > >tB eanInfoImpl.java:85)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
> >
> > > >tB eanInfoImpl.java:127)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementB
> >
> > > >ea nInfoImpl.java:244)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementB
> >
> > > >ea nInfoImpl.java:251)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementB
> >
> > > >ea nInfoImpl.java:33)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.ja
> >
> > > >va
> > > >
> > > > :461)
> > > >
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:2
> >
> > > >92 )
> > > > ... 26 more
> > > > Caused by: javax.xml.bind.JAXBException:
> > > > com.basistech.ws.fortest.TestException is not known to this
> > > > context at
> >
> >
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImp
> >
> > > >l. java:538)
> > > > at
> >
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
> >
> > > >tB eanInfoImpl.java:82)
> > > > ... 32 more
> > > > Oct 18, 2007 8:22:55 PM
> > > > org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback
> > > > onClose
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer
> > > IONA
> > > P: 781-902-8727 C: 508-380-7194
> > > daniel.kulp@iona.com
> > > http://www.dankulp.com/blog
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
Re: JAXB + JAX-WS + faults
Posted by Daniel Kulp <dk...@apache.org>.
On Friday 19 October 2007, Benson Margulies wrote:
> Should we reduce the logging noisiness of this process?
That's a good question. I can definitely see taking the stack trace off
of it. That's just scary to users. I'd probably change the message
to:
Exception occurred while writing user fault. {0} Delegating to binding
fault writing routines.
Next question: what log level? FINE, INFO, WARNING?
Next: should we keep track of the classes that we couldn't write and just
log on the FIRST time that type is encountered?
Thoughts?
Dan
>
> > -----Original Message-----
> > From: Daniel Kulp [mailto:dkulp@apache.org]
> > Sent: Friday, October 19, 2007 1:01 PM
> > To: cxf-user@incubator.apache.org
> > Cc: Benson Margulies
> > Subject: Re: JAXB + JAX-WS + faults
> >
> >
> > Benson,
> >
> > This is a sideaffect of the fixes we did for the Aegis faults with
> > the JAX-WS frontend. By making the WebFaultOutInterceptor delegate
> > up to the normal fault handling, the databinding gets a crack at
> > trying to write the fault.
> >
> > In 2.0.2, if the exception didn't have an @WebFault, the
> > WebFaultOutInterceptor would ignore it and then the SOAPFaultOut
> > stuff would then just map the getMessage() call onto the wire an no
> > other
>
> data
>
> > would get sent on the wire.
> >
> > With 2.0.3, the superclass gets a chance which basically feeds the
>
> fault
>
> > into the databinding writer. In this case, JAXB doesn't know what
> > to
>
> do
>
> > with it and throws an exception. The FaultOutInterceptor does
>
> swallow
>
> > that exception so it does properly go to the SOAPFaultOut stuff as
> > before, but I did log it so you know any detail that may be in the
> > Exception that you expected to be on the wire won't be there. The
> > databinding had no clue what to do with it.
> >
> >
> > Dan
> >
> > On Thursday 18 October 2007, Benson Margulies wrote:
> > > Since moving to the latest 2.0.3 snapshot, I'm getting an
> > > exception when marshalling a fault declared on a 'throws' clause.
> > > No
>
> @WebFault.
>
> > > This didn't happen with 2.0.2 afaik.
> > >
> > > WARNING: Exception occurred while writing fault.
> > > org.apache.cxf.interceptor.Fault: Marshalling Error:
> > > com.basistech.ws.fortest.TestException is not known to this
> > > context at
>
> org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.jav
>
> > >a: 179)
> > > at
> > > org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:42
> > >) at
>
> org.apache.cxf.interceptor.FaultOutInterceptor.handleMessage(FaultOutI
>
> > >nt erceptor.java:75)
> > > at
>
> org.apache.cxf.jaxws.interceptors.WebFaultOutInterceptor.handleMessage
>
> > >(W ebFaultOutInterceptor.java:127)
> > > at
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>
> > >rC hain.java:207)
> > > at
>
> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessa
>
> > >ge (AbstractFaultChainInitiatorObserver.java:90)
> > > at
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>
> > >rC hain.java:224)
> > > at
>
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
>
> > >ti onObserver.java:73)
> > > at
>
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceReques
>
> > >t( JettyHTTPDestination.java:282)
> > > at
>
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(Jet
>
> > >ty HTTPDestination.java:238)
> > > at
>
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPH
>
> > >an dler.java:54)
> > > at
>
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:71
>
> > >2) at
>
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandl
>
> > >er Collection.java:211)
> > > at
> > > org.mortbay.jetty.handler.HandlerList.handle(HandlerList.java:49)
> > > at
>
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:13
>
> > >9) at org.mortbay.jetty.Server.handle(Server.java:313)
> > > at
>
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506
>
> > >) at
>
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection
>
> > >.j ava:844)
> > > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
> > > at
> > > org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> > > at
> > > org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
> > > at
>
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.jav
>
> > >a: 396)
> > > at
>
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.
>
> > >ja va:442)
> > > Caused by: javax.xml.bind.MarshalException
> > > - with linked exception:
> > > [javax.xml.bind.JAXBException:
>
> com.basistech.ws.fortest.TestException
>
> > > is not known to this context]
> > > at
>
> com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:2
>
> > >95 )
> > > at
>
> com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java
>
> > >:2 21)
> > >
> > > at
>
> javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshall
>
> > >er Impl.java:91)
> > > at
>
> org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.
>
> > >ja va:192)
> > > at
>
> org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.jav
>
> > >a: 167)
> > > ... 22 more
> > > Caused by: javax.xml.bind.JAXBException:
> > > com.basistech.ws.fortest.TestException is not known to this
> > > context at
>
> com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.ja
>
> > >va
> > >
> > > :223)
> > >
> > > at
>
> com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.ja
>
> > >va
> > >
> > > :238)
> > >
> > > at
>
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
>
> > >tB eanInfoImpl.java:85)
> > > at
>
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
>
> > >tB eanInfoImpl.java:127)
> > > at
>
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementB
>
> > >ea nInfoImpl.java:244)
> > > at
>
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementB
>
> > >ea nInfoImpl.java:251)
> > > at
>
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementB
>
> > >ea nInfoImpl.java:33)
> > > at
>
> com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.ja
>
> > >va
> > >
> > > :461)
> > >
> > > at
>
> com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:2
>
> > >92 )
> > > ... 26 more
> > > Caused by: javax.xml.bind.JAXBException:
> > > com.basistech.ws.fortest.TestException is not known to this
> > > context at
>
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImp
>
> > >l. java:538)
> > > at
>
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
>
> > >tB eanInfoImpl.java:82)
> > > ... 32 more
> > > Oct 18, 2007 8:22:55 PM
> > > org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback
> > > onClose
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727 C: 508-380-7194
> > daniel.kulp@iona.com
> > http://www.dankulp.com/blog
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: JAXB + JAX-WS + faults
Posted by Benson Margulies <bi...@basistech.com>.
Should we reduce the logging noisiness of this process?
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, October 19, 2007 1:01 PM
> To: cxf-user@incubator.apache.org
> Cc: Benson Margulies
> Subject: Re: JAXB + JAX-WS + faults
>
>
> Benson,
>
> This is a sideaffect of the fixes we did for the Aegis faults with the
> JAX-WS frontend. By making the WebFaultOutInterceptor delegate up to
> the normal fault handling, the databinding gets a crack at trying to
> write the fault.
>
> In 2.0.2, if the exception didn't have an @WebFault, the
> WebFaultOutInterceptor would ignore it and then the SOAPFaultOut stuff
> would then just map the getMessage() call onto the wire an no other
data
> would get sent on the wire.
>
> With 2.0.3, the superclass gets a chance which basically feeds the
fault
> into the databinding writer. In this case, JAXB doesn't know what to
do
> with it and throws an exception. The FaultOutInterceptor does
swallow
> that exception so it does properly go to the SOAPFaultOut stuff as
> before, but I did log it so you know any detail that may be in the
> Exception that you expected to be on the wire won't be there. The
> databinding had no clue what to do with it.
>
>
> Dan
>
>
> On Thursday 18 October 2007, Benson Margulies wrote:
> > Since moving to the latest 2.0.3 snapshot, I'm getting an exception
> > when marshalling a fault declared on a 'throws' clause. No
@WebFault.
> > This didn't happen with 2.0.2 afaik.
> >
> > WARNING: Exception occurred while writing fault.
> > org.apache.cxf.interceptor.Fault: Marshalling Error:
> > com.basistech.ws.fortest.TestException is not known to this context
> > at
> >
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.jav
> >a: 179)
> > at
> > org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:42)
> > at
> >
org.apache.cxf.interceptor.FaultOutInterceptor.handleMessage(FaultOutI
> >nt erceptor.java:75)
> > at
> >
org.apache.cxf.jaxws.interceptors.WebFaultOutInterceptor.handleMessage
> >(W ebFaultOutInterceptor.java:127)
> > at
> >
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> >rC hain.java:207)
> > at
> >
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessa
> >ge (AbstractFaultChainInitiatorObserver.java:90)
> > at
> >
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> >rC hain.java:224)
> > at
> >
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
> >ti onObserver.java:73)
> > at
> >
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceReques
> >t( JettyHTTPDestination.java:282)
> > at
> >
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(Jet
> >ty HTTPDestination.java:238)
> > at
> >
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPH
> >an dler.java:54)
> > at
> >
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:71
> >2) at
> >
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandl
> >er Collection.java:211)
> > at
> > org.mortbay.jetty.handler.HandlerList.handle(HandlerList.java:49)
> > at
> >
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:13
> >9) at org.mortbay.jetty.Server.handle(Server.java:313)
> > at
> >
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506
> >) at
> >
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection
> >.j ava:844)
> > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
> > at
> > org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> > at
> > org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
> > at
> >
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.jav
> >a: 396)
> > at
> >
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.
> >ja va:442)
> > Caused by: javax.xml.bind.MarshalException
> > - with linked exception:
> > [javax.xml.bind.JAXBException:
com.basistech.ws.fortest.TestException
> > is not known to this context]
> > at
> >
com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:2
> >95 )
> > at
> >
com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java
> >:2 21)
> > at
> >
javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshall
> >er Impl.java:91)
> > at
> >
org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.
> >ja va:192)
> > at
> >
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.jav
> >a: 167)
> > ... 22 more
> > Caused by: javax.xml.bind.JAXBException:
> > com.basistech.ws.fortest.TestException is not known to this context
> > at
> >
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.ja
> >va
> >
> > :223)
> >
> > at
> >
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.ja
> >va
> >
> > :238)
> >
> > at
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
> >tB eanInfoImpl.java:85)
> > at
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
> >tB eanInfoImpl.java:127)
> > at
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementB
> >ea nInfoImpl.java:244)
> > at
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementB
> >ea nInfoImpl.java:251)
> > at
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementB
> >ea nInfoImpl.java:33)
> > at
> >
com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.ja
> >va
> >
> > :461)
> >
> > at
> >
com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:2
> >92 )
> > ... 26 more
> > Caused by: javax.xml.bind.JAXBException:
> > com.basistech.ws.fortest.TestException is not known to this context
> > at
> >
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImp
> >l. java:538)
> > at
> >
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
> >tB eanInfoImpl.java:82)
> > ... 32 more
> > Oct 18, 2007 8:22:55 PM
> > org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback
> > onClose
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
Re: JAXB + JAX-WS + faults
Posted by Daniel Kulp <dk...@apache.org>.
Benson,
This is a sideaffect of the fixes we did for the Aegis faults with the
JAX-WS frontend. By making the WebFaultOutInterceptor delegate up to
the normal fault handling, the databinding gets a crack at trying to
write the fault.
In 2.0.2, if the exception didn't have an @WebFault, the
WebFaultOutInterceptor would ignore it and then the SOAPFaultOut stuff
would then just map the getMessage() call onto the wire an no other data
would get sent on the wire.
With 2.0.3, the superclass gets a chance which basically feeds the fault
into the databinding writer. In this case, JAXB doesn't know what to do
with it and throws an exception. The FaultOutInterceptor does swallow
that exception so it does properly go to the SOAPFaultOut stuff as
before, but I did log it so you know any detail that may be in the
Exception that you expected to be on the wire won't be there. The
databinding had no clue what to do with it.
Dan
On Thursday 18 October 2007, Benson Margulies wrote:
> Since moving to the latest 2.0.3 snapshot, I'm getting an exception
> when marshalling a fault declared on a 'throws' clause. No @WebFault.
> This didn't happen with 2.0.2 afaik.
>
> WARNING: Exception occurred while writing fault.
> org.apache.cxf.interceptor.Fault: Marshalling Error:
> com.basistech.ws.fortest.TestException is not known to this context
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.jav
>a: 179)
> at
> org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:42)
> at
> org.apache.cxf.interceptor.FaultOutInterceptor.handleMessage(FaultOutI
>nt erceptor.java:75)
> at
> org.apache.cxf.jaxws.interceptors.WebFaultOutInterceptor.handleMessage
>(W ebFaultOutInterceptor.java:127)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>rC hain.java:207)
> at
> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessa
>ge (AbstractFaultChainInitiatorObserver.java:90)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>rC hain.java:224)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
>ti onObserver.java:73)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceReques
>t( JettyHTTPDestination.java:282)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(Jet
>ty HTTPDestination.java:238)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPH
>an dler.java:54)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:71
>2) at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandl
>er Collection.java:211)
> at
> org.mortbay.jetty.handler.HandlerList.handle(HandlerList.java:49)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:13
>9) at org.mortbay.jetty.Server.handle(Server.java:313)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506
>) at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection
>.j ava:844)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
> at
> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> at
> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.jav
>a: 396)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.
>ja va:442)
> Caused by: javax.xml.bind.MarshalException
> - with linked exception:
> [javax.xml.bind.JAXBException: com.basistech.ws.fortest.TestException
> is not known to this context]
> at
> com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:2
>95 )
> at
> com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java
>:2 21)
> at
> javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshall
>er Impl.java:91)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.
>ja va:192)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.jav
>a: 167)
> ... 22 more
> Caused by: javax.xml.bind.JAXBException:
> com.basistech.ws.fortest.TestException is not known to this context
> at
> com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.ja
>va
>
> :223)
>
> at
> com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.ja
>va
>
> :238)
>
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
>tB eanInfoImpl.java:85)
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
>tB eanInfoImpl.java:127)
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementB
>ea nInfoImpl.java:244)
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementB
>ea nInfoImpl.java:251)
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementB
>ea nInfoImpl.java:33)
> at
> com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.ja
>va
>
> :461)
>
> at
> com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:2
>92 )
> ... 26 more
> Caused by: javax.xml.bind.JAXBException:
> com.basistech.ws.fortest.TestException is not known to this context
> at
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImp
>l. java:538)
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Elemen
>tB eanInfoImpl.java:82)
> ... 32 more
> Oct 18, 2007 8:22:55 PM
> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback
> onClose
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog