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:[EMAIL PROTECTED] > Sent: Wednesday, October 03, 2007 12:06 PM > To: Benson Margulies > Cc: [email protected] > 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:[EMAIL PROTECTED] > > > Sent: Wednesday, October 03, 2007 11:27 AM > > > To: [email protected] > > > 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 > > > [EMAIL PROTECTED] > > > http://www.dankulp.com/blog > > > > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED] > http://www.dankulp.com/blog
