You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Edward W. Rouse" <er...@comsquared.com> on 2013/05/06 18:55:36 UTC
axis 1.4 client to cxf 2.0 service
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.
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
Re: axis 1.4 client to cxf 2.0 service
Posted by Sergey Beryozkin <sb...@gmail.com>.
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:erouse@comsquared.com]
>> Sent: Monday, May 06, 2013 3:43 PM
>> To: users@cxf.apache.org
>> Subject: RE: axis 1.4 client to cxf 2.0 service
>>
>>
>>
>>> -----Original Message-----
>>> From: Daniel Kulp [mailto:dkulp@apache.org]
>>> Sent: Monday, May 06, 2013 3:38 PM
>>> To: users@cxf.apache.org; 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<er...@comsquared.com>
>>> 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
>>> dkulp@apache.org - 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
RE: axis 1.4 client to cxf 2.0 service
Posted by "Edward W. Rouse" <er...@comsquared.com>.
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:erouse@comsquared.com]
> Sent: Monday, May 06, 2013 3:43 PM
> To: users@cxf.apache.org
> Subject: RE: axis 1.4 client to cxf 2.0 service
>
>
>
> > -----Original Message-----
> > From: Daniel Kulp [mailto:dkulp@apache.org]
> > Sent: Monday, May 06, 2013 3:38 PM
> > To: users@cxf.apache.org; 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 <er...@comsquared.com>
> > 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
> > dkulp@apache.org - 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.
RE: axis 1.4 client to cxf 2.0 service
Posted by "Edward W. Rouse" <er...@comsquared.com>.
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Monday, May 06, 2013 3:38 PM
> To: users@cxf.apache.org; 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 <er...@comsquared.com>
> 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
> dkulp@apache.org - 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.
Re: axis 1.4 client to cxf 2.0 service
Posted by Daniel Kulp <dk...@apache.org>.
On May 6, 2013, at 12:55 PM, Edward W. Rouse <er...@comsquared.com> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com