I kind of fixed this one by taking the most recent version of the old client and removing the guts of the methods and replacing them with calls that use cxf. I had to do a little manual work, adding limited cxf jar files and removing the old axis1.4.jar file, but it does communicate. The current problem is that I can't seem to gain access to the context. The original code used the MessageContext from the axis1.4.jar file, which I had to remove. I have tried : @Resource private WebServiceContext context;
and @Context with MessageContext, but keep getting a null context. Any ideas on how I can get access to the context (or the session) to store session variables? > -----Original Message----- > From: Edward W. Rouse [mailto:[email protected]] > Sent: Monday, May 06, 2013 3:43 PM > To: [email protected] > Subject: RE: axis 1.4 client to cxf 2.0 service > > > > > -----Original Message----- > > From: Daniel Kulp [mailto:[email protected]] > > Sent: Monday, May 06, 2013 3:38 PM > > To: [email protected]; Edward W. Rouse > > Subject: Re: axis 1.4 client to cxf 2.0 service > > > > > > On May 6, 2013, at 12:55 PM, Edward W. Rouse <[email protected]> > > wrote: > > > > > I have old web service that was generated/written using axis 1.4. > > There are > > > many end user written clients that use this web service. There was > a > > > complete rewrite recently done by another group that completely > > changed the > > > interfaces and was generated/written using cxf 2.x. I have been > > tasked with > > > writing a conversion program that will accept the old axis 1.4 > calls, > > > convert them and make corresponding calls to the cxf services, > accept > > the > > > responses and convert them into the expected axis 1.4 responses and > > send > > > them back to the client. > > > > > > The current roadblock is an "org.apache.cxf.interceptor.Fault: > > Unexpected > > > wrapper element <connect> found. Expected <connect>." exception. > > > > Wow. That's really strange. The code around there specifically > > checks a .equals on the qnames, but the above message makes it sound > > like the two are equal. Strange. > > > > That said, a wrapper element should be namespace qualified which the > > above doesn't have. > > > > Have you looked into the CXF transformation features? > > http://cxf.apache.org/docs/transformationfeature.html > > > > it can handle some basic element renaming and namespace mapping and > > such. You may be able to get the service to accept the original > Axis1 > > requests automatically and not really need a proxy. > > > > Dan > > > > > > > > > This is thrown when trying to connect using an original client. My > > > assumption is that, even though the wsdl file used is the same, the > > soap > > > headers are different. Any idea how to set the incoming > > calls/responses to > > > use axis while the outgoing calls/responses use cxf? > > > > > > In order to try and be less ambiguous, here is a (poor) diagram. > > > > > > Request > > > client(axis1.4) --> proxy service(axis1.4) --> proxy > service(cxf2.x) > > --> new > > > service(cxf2.x) > > > > > > Response > > > client(axis1.4) <-- proxy service(axis1.4) <-- proxy > service(cxf2.x) > > <-- new > > > service(cxf2.x) > > > > > > Edward W. Rouse > > > > > > > -- > > Daniel Kulp > > [email protected] - http://dankulp.com/blog > > Talend Community Coder - http://coders.talend.com > > > I'll take a look, thanks. Just as a note, The original message was name > space qualified. I took that out due to company policy. And the > namespace > was identical. I always use <> to indicate a placeholder, and the 2 > items > the placeholders represent were identical.
