On 06/05/13 22:56, Edward W. Rouse wrote:
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?
@Context with MessageContext will only work if the JAX-RS frontend is
also loaded,
but @Resource with WebServiceContext should work, unless you have Spring
or Blueprint proxifying the service implementations which usually hides
the fields; with JAXWS you can use a @serviceClass attribute to hint at
the actual service class, introducing an interface with a method like
@Resource
void setWebServiceContext(WebServiceContext context) {}
and service class implementing it
should also do it
Cheers, Sergey
-----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.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
