cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <bim2...@basistech.com>
Subject RE: 1080
Date Wed, 03 Oct 2007 16:09:06 GMT
I'm having the same experience you are. I've sorted out the endpoints,
and I get results that align much more with what you are writing here.
I'm no longer seeing the namespace mismatch, but no fault detail
whatsoever.

This suggests that in my code that started all this, I need an @WebFault
if I want specific faults. Or I need to switch to the simple front end
altogether?

> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Wednesday, October 03, 2007 12:06 PM
> To: Benson Margulies
> Cc: cxf-dev@incubator.apache.org
> Subject: Re: 1080
> 
> On Wednesday 03 October 2007, Benson Margulies wrote:
> > I can't figure out how this matches up with the fact that the JAX-WS
> > spec I read said that @WebFault shouldn't be needed,
> 
> That's a separate issue.   The JAX-WS WebFaultOutInterceptor should
> subclass the FaultOutInterceptor and if there isn't a WebFault
> annotation, delegate to the parent class.   That's definitely true.
:-(
> 
> Currently, if there isn't a WebFault annotation, we just let it go to
the
> Soap11FaultOutInterceptor which creates a generic fault and the detail
> stuff is completely lost.
> 
> > and that what I
> > saw in the debugger was a very simple namespace mismatch between the
> > server and the client.
> 
> Right.   Which MAY be due to the type <--> element thing.     Not
sure.
> 
> 
> > All the setup does is set an Aegis databinding and the Aegis service
> > configuration thing that porks the namespace.
> 
> Well, the big thing I see is that all the services are on:
> local://ExceptionService
> but it looks like it's the "first one wins" type thing.   If I change
> that address for the other tests, I do get furthur.   With the
> WebFaultOut subclass thing and changing the address, the last two
tests
> you have DO pass.
> 
> Dan
> 
> 
> >
> > > -----Original Message-----
> > > From: Daniel Kulp [mailto:dkulp@apache.org]
> > > Sent: Wednesday, October 03, 2007 11:27 AM
> > > To: cxf-dev@incubator.apache.org
> > > Cc: Benson Margulies
> > > Subject: Re: 1080
> > >
> > >
> > > Benson,
> > >
> > > On Wednesday 03 October 2007, Benson Margulies wrote:
> > > > I've put some time into this, and I'm beginning to wonder if I'm
> > > > debugging a feature. I can't seem to quite pin down how it is
that
> >
> > the
> >
> > > > use of the JaxWs client proxy fails to convert exception
classes.
> > > > Maybe I should try some more when I've had some breakfast, but
it
> >
> > sure
> >
> > > > would be nice if someone would tell me that this test case
should,
> >
> > in
> >
> > > > fact, pass.
> > >
> > > I'm digging into this a bit and find a bunch of issues...
> > >
> > > 1) Somehow, the stuff in your setUp method is screwing things up.
> >
> > That
> >
> > > service is getting the request and that isn't setup with JAX-WS.
> > > The generic FaultOutInterceptor is being used instead of the
JAX-WS
> > > WebFaultOutInterceptor.
> > >
> > > 2) With JAX-WS, the Exception would need a @WebFault annotation
> > > added.
> > >
> > > 3) Even with that, it's not working.   The aegis stuff is mapping
> > > the fault parts in the wsdl message as type="xxxx" instead of
> > > element="xxxx".  That needs to be fixed.   That, in combination
with
> >
> > the
> >
> > > other two SHOULD get it working.    We just need to figure out how
> > > to get the aegis stuff to do elements instead of types.
> > >
> > >
> > >
> > > --
> > > 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

Mime
View raw message