Issue CXF-1080 in Jira. Dan
On Thursday 04 October 2007, Sergey Beryozkin wrote: > Just curious, what "1080" means ? Having more descriptive subject > lines would help :-) > > Thanks, Sergey > > > ----- Original Message ----- > From: "Benson Margulies" <[EMAIL PROTECTED]> > To: "Daniel Kulp" <[EMAIL PROTECTED]> > Cc: <[email protected]> > Sent: Wednesday, October 03, 2007 5:09 PM > Subject: RE: 1080 > > > 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 > > ---------------------------- > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, > Ireland -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
