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, and that what I saw in the debugger was a very simple namespace mismatch between the server and the client.
All the setup does is set an Aegis databinding and the Aegis service configuration thing that porks the namespace. > -----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
