Not sure why you don't feel this is a good solution. When our company hired Dan 
Diephouse to architect our new web structure, that's how he initially taught me 
to do the service interfaces. Example:
 
@WebService
public interface ReportService
{
   @WebResult(name = "ReportResult")
   String getSummaryReport(@WebParam(name = "location") String location,
                           @WebParam(name = "fromDate") String fromDate,
                           @WebParam(name = "toDate")   String toDate)
   throws ReportFault;
}
 
Also, I've never had to declare the namespace as you've done, and it's always 
worked fine.
 
Anyway, glad you got it working.
 
Ron Grimes
 

________________________________

From: Kevin Priebe [mailto:[email protected]]
Sent: Thu 3/12/2009 5:28 PM
To: [email protected]
Subject: RE: XFire migration - old client doesn't send named parameters



Ok, I have a working solution, although not a pretty one.  I have named the 
parameters, so that XFire requests will be accepted like so:

@WebService(targetNamespace="http://service.realtyserver.com 
<http://service.realtyserver.com/> ")
public interface IAuthService {
        public boolean ping(@WebParam(name="in0", 
targetNamespace="http://service.realtyserver.com 
<http://service.realtyserver.com/> ") String board);
}

I had to name it in0, AND set the namespace to not have a / at the end, since 
that was causing problems for some reason again (I thought it was working 
before because of the XFireCompatibilityServiceConfiguration bean...).  Now 
both XFire and CXF clients work... for this 1 method.  Now the test for all web 
services.

If anyone has a better/nicer solution to this, please let me know.  At the very 
least I will leave it like this for a few months, and then name the parameters 
correctly as the XFire clients are phased out.

Kevin


-----Original Message-----
From: Kevin Priebe [mailto:[email protected]]
Sent: March-12-09 3:31 PM
To: [email protected]
Subject: RE: XFire migration - old client doesn't send named parameters

Part of the problem is that if there are no names specified, then the CXF 
server expects anonymized names like arg0, arg1, but the XFire client sends as 
in0, in1 (whether the WSDL specifies names or not).

Note that I can't change the XFire client, so I'm hoping for a workaround for 
this on the server so that it will accept requests from XFire or CXF clients.  
I have even tried naming the parameters specifically as @WebParam(name="in0"), 
which is a big hack but I'm getting desperate.  It still doesn't work because 
XFire sends <ns1:in0>testValue</ns1:in0> instead of <in0>testValue</in0> (which 
my new CXF client sends), and even that seems to mess up the server and makes 
the value NULL when received.

I am still testing different possibilities, but am running out of ideas.  
Thanks for the help,

Kevin


-----Original Message-----
From: Benson Margulies [mailto:[email protected]]
Sent: March-12-09 2:43 PM
To: [email protected]
Subject: Re: XFire migration - old client doesn't send named parameters

No, I'm attention-deprived.

The simplest thing to do is set the names with .aegis.xml files. Or,
be sure to only feed CXF an interface, not a real class. There are no
parameter names in an interface, so it will, I think, come up with the
same anonymized names.

On Thu, Mar 12, 2009 at 5:27 PM, Kevin Priebe <[email protected]> wrote:
> I put in the original email "I am using XFire 1.2.6 (was using simple 
> frontend and aegis) and CXF 2.1.4 (with jaxws and aegis).  All using tomcat 
> with spring server config.".  So I am using the aegis binding.  Sorry the 
> email was probably a little long...
>
> Kevin
>
>
> -----Original Message-----
> From: Benson Margulies [mailto:[email protected]]
> Sent: March-12-09 2:19 PM
> To: [email protected]
> Subject: Re: XFire migration - old client doesn't send named parameters
>
> What data binding are you using? What  version of CXF?
>
>
>
> On Thu, Mar 12, 2009 at 2:10 PM, Kevin Priebe <[email protected]> wrote:
>> Hi, I have ported all of our XFire services/clients to CXF and only have 1
>> outstanding issue that is preventing any old XFire clients from working with
>> the new CXF service.  Our old XFire clients seem to send non-named
>> parameters (in0, in1) like so:
>>
>>
>>
>> <soap:Body><ns1:ping
>> xmlns:ns1="http://service.realtyserver.com 
>> <http://service.realtyserver.com/> "><ns1:in0>testValue</ns1:in0></ns
>> 1:ping></soap:Body>
>>
>>
>>
>> Whereas the WSDL has the 'in0' parameter named as 'board'.  This causes the
>> parameter to be NULL when received.  The new CXF client correctly sends like
>> so:
>>
>>
>>
>> <soap:Body><ns1:ping
>> xmlns:ns1="http://service.realtyserver.com/";><board>testValue</board></ns1:p
>> ing></soap:Body>
>>
>>
>>
>> The missing slash was also a problem, but that has been resolved since if I
>> manually change the XFire request in0 -> board, and resend the request it
>> works.  So I just need to figure out the parameter problem.
>>
>>
>>
>> I would really like to make this backwards compatible for the old XFire
>> clients at least for a few months while we make the transition.  Is there
>> any workaround for this?
>>
>>
>>
>> I am using XFire 1.2.6 (was using simple frontend and aegis) and CXF 2.1.4
>> (with jaxws and aegis).  All using tomcat with spring server config.
>>
>>
>>
>> I have tried the simple frontend and now am trying the jaxws frontend with
>> annotated web services to name the parameters using @WebParam since the
>> simple frontend was causing the CXF client to send parameters as arg0, arg1
>> etc.  Here are the relevant files:
>>
>>
>>
>> @WebService
>>
>> public interface IAuthService {
>>
>>                public boolean ping(@WebParam(name="board") String board);
>>
>> }
>>
>>
>>
>> @WebService(endpointInterface="com.realtyserver.service.IAuthService",
>> serviceName="AuthService")
>>
>> public class AuthService implements IAuthService {
>>
>>                public boolean ping(String board) {
>>
>>                                return true;
>>
>>                }
>>
>> }
>>
>>
>>
>> cxf.xml
>>
>> --------
>>
>>
>>
>> <bean id="aegisBean"
>> class="org.apache.cxf.aegis.databinding.AegisDatabinding"
>> scope="prototype"/>
>>
>>
>>
>> <bean id="jaxws-and-aegis-service-factory"
>>
>>
>> class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean"
>>
>>                                scope="prototype">
>>
>>                                <property name="dataBinding"
>> ref="aegisBean"/>
>>
>>                                <property name="serviceConfigurations">
>>
>>                                <list>
>>
>>                                                <bean
>> class="org.apache.cxf.jaxws.support.JaxWsServiceConfiguration"/>
>>
>>                                                <bean
>> class="org.apache.cxf.aegis.databinding.XFireCompatibilityServiceConfigurati
>> on"/>
>>
>>                                                <bean
>> class="org.apache.cxf.service.factory.DefaultServiceConfiguration"/>
>>
>>                                </list>
>>
>>                </property>
>>
>> </bean>
>>
>>
>>
>> <bean id="AuthServiceImpl" class="serviceImpl.AuthService"/>
>>
>>
>>
>> <jaxws:endpoint id="AuthServceEndpoint" address="/AuthService"
>> implementor="#AuthServiceImpl">
>>
>>                <jaxws:serviceFactory>
>>
>>                                <ref bean="jaxws-and-aegis-service-factory"
>> />
>>
>>                </jaxws:serviceFactory>
>>
>> </jaxws:endpoint>
>>
>>
>>
>> Thanks for any help.
>>
>> Kevin
>>
>>
>>
>>
>
>



Reply via email to