cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: axis 1.4 client to cxf 2.0 service
Date Tue, 07 May 2013 08:57:03 GMT
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<erouse@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

Mime
View raw message