Well, you could make your own ServiceConfiguration object that just serially assigned the names.
On Thu, Mar 12, 2009 at 7:28 PM, Kevin Priebe <[email protected]> wrote: > 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";) > public interface IAuthService { > public boolean ping(@WebParam(name="in0", > targetNamespace="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";><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 >>> >>> >>> >>> >> >> > >
