You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Kevin Priebe <ke...@realtyserver.com> on 2009/03/12 19:10:41 UTC

XFire migration - old client doesn't send named parameters

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

 


Re: XFire migration - old client doesn't send named parameters

Posted by Benson Margulies <bi...@gmail.com>.
Sorry to tune in so slowly.

Can you post an entire XML message? It was my belief that Aegis
wouldn't ever do unqualified elements, so I'm a bit puzzled by <in0>
with no colon, unless there is an xmlns. You need to set the namespace
on the @WebParam so that it is in whatever namespace goes with ns1. I

As an alternative.

You could generate a JAX-WS + JAXB client with wsdl2java using the
XFire-produced WSDL. The generated classes will look pretty different
than the ones on your server, but you could then proceed to fiddle
until they cooperated.



On Thu, Mar 12, 2009 at 6:31 PM, Kevin Priebe <ke...@realtyserver.com> wrote:
> 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:bimargulies@gmail.com]
> Sent: March-12-09 2:43 PM
> To: users@cxf.apache.org
> 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 <ke...@realtyserver.com> 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:bimargulies@gmail.com]
>> Sent: March-12-09 2:19 PM
>> To: users@cxf.apache.org
>> 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 <ke...@realtyserver.com> 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
>>>
>>>
>>>
>>>
>>
>>
>
>

RE: XFire migration - old client doesn't send named parameters

Posted by Kevin Priebe <ke...@realtyserver.com>.
The only reason I don't like it is because I have to name all the parameters
in0, in1 etc. instead of real names so that the old XFire clients still
work.  This is because the services were not annotated before and I can't
change the XFire clients at this point.  Otherwise it would be fine.  But
like I said, I can just rename them in a few months once the transition
period is over and we will stop supporting the old XFire clients.

I am still experimenting with the namespace issue. It has to do with XFire
not including a / at the end, but CXF does, so it just doesn't work without
the / for some reason.  So I am manually setting the namespace to NOT have a
/ at the end so the old XFire clients work as well as the new CXF one.

Benson:  I will look into a custom service factory.  Thanks for the
suggestion.

Kevin
 
-----Original Message-----
From: Ron Grimes [mailto:rgrimes@sinclairoil.com] 
Sent: March-12-09 5:14 PM
To: users@cxf.apache.org
Subject: RE: XFire migration - old client doesn't send named parameters

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:kevin@realtyserver.com]
Sent: Thu 3/12/2009 5:28 PM
To: users@cxf.apache.org
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:kevin@realtyserver.com]
Sent: March-12-09 3:31 PM
To: users@cxf.apache.org
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:bimargulies@gmail.com]
Sent: March-12-09 2:43 PM
To: users@cxf.apache.org
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 <ke...@realtyserver.com>
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:bimargulies@gmail.com]
> Sent: March-12-09 2:19 PM
> To: users@cxf.apache.org
> 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 <ke...@realtyserver.com>
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
>>
>>
>>
>>
>
>





RE: XFire migration - old client doesn't send named parameters

Posted by Ron Grimes <rg...@sinclairoil.com>.
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:kevin@realtyserver.com]
Sent: Thu 3/12/2009 5:28 PM
To: users@cxf.apache.org
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:kevin@realtyserver.com]
Sent: March-12-09 3:31 PM
To: users@cxf.apache.org
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:bimargulies@gmail.com]
Sent: March-12-09 2:43 PM
To: users@cxf.apache.org
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 <ke...@realtyserver.com> 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:bimargulies@gmail.com]
> Sent: March-12-09 2:19 PM
> To: users@cxf.apache.org
> 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 <ke...@realtyserver.com> 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
>>
>>
>>
>>
>
>




Re: XFire migration - old client doesn't send named parameters

Posted by Benson Margulies <bi...@gmail.com>.
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 <ke...@realtyserver.com> 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:kevin@realtyserver.com]
> Sent: March-12-09 3:31 PM
> To: users@cxf.apache.org
> 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:bimargulies@gmail.com]
> Sent: March-12-09 2:43 PM
> To: users@cxf.apache.org
> 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 <ke...@realtyserver.com> 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:bimargulies@gmail.com]
>> Sent: March-12-09 2:19 PM
>> To: users@cxf.apache.org
>> 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 <ke...@realtyserver.com> 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
>>>
>>>
>>>
>>>
>>
>>
>
>

RE: XFire migration - old client doesn't send named parameters

Posted by Kevin Priebe <ke...@realtyserver.com>.
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:kevin@realtyserver.com] 
Sent: March-12-09 3:31 PM
To: users@cxf.apache.org
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:bimargulies@gmail.com] 
Sent: March-12-09 2:43 PM
To: users@cxf.apache.org
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 <ke...@realtyserver.com> 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:bimargulies@gmail.com]
> Sent: March-12-09 2:19 PM
> To: users@cxf.apache.org
> 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 <ke...@realtyserver.com> 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
>>
>>
>>
>>
>
>


RE: XFire migration - old client doesn't send named parameters

Posted by Kevin Priebe <ke...@realtyserver.com>.
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:bimargulies@gmail.com] 
Sent: March-12-09 2:43 PM
To: users@cxf.apache.org
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 <ke...@realtyserver.com> 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:bimargulies@gmail.com]
> Sent: March-12-09 2:19 PM
> To: users@cxf.apache.org
> 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 <ke...@realtyserver.com> 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
>>
>>
>>
>>
>
>


Re: XFire migration - old client doesn't send named parameters

Posted by Benson Margulies <bi...@gmail.com>.
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 <ke...@realtyserver.com> 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:bimargulies@gmail.com]
> Sent: March-12-09 2:19 PM
> To: users@cxf.apache.org
> 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 <ke...@realtyserver.com> 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
>>
>>
>>
>>
>
>

RE: XFire migration - old client doesn't send named parameters

Posted by Kevin Priebe <ke...@realtyserver.com>.
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:bimargulies@gmail.com] 
Sent: March-12-09 2:19 PM
To: users@cxf.apache.org
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 <ke...@realtyserver.com> 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
>
>
>
>


Re: XFire migration - old client doesn't send named parameters

Posted by Benson Margulies <bi...@gmail.com>.
What data binding are you using? What  version of CXF?



On Thu, Mar 12, 2009 at 2:10 PM, Kevin Priebe <ke...@realtyserver.com> 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
>
>
>
>

RE: XFire migration - old client doesn't send named parameters

Posted by yannick1976 <ya...@yahoo.fr>.
Hello all !

Pretty much as the author of this thread, we are upgrading our webservices
framework from XFire to CXF and we need to keep the contract unchanged.

I realized most of the changes can be avoided by using a Simple Frontend and
aegis binding and adding XFireCompatibilityServiceConfiguration service
configuration to the factory. By the way, I couldn't find any documentation
on how to do it with a simple frontend so here is how I did it :
<simple:server id="minimal" serviceClass="test.minimal.Minimal"
address="/minimal">
    <simple:serviceBean>
        <bean class="test.minimal.MinimalImpl" />
    </simple:serviceBean>
    <simple:dataBinding>
        <bean class="org.apache.cxf.aegis.databinding.AegisDatabinding" />
    </simple:dataBinding>
    <simple:serviceFactory>
        <bean
class="org.apache.cxf.service.factory.ReflectionServiceFactoryBean">
            <property name="serviceConfigurations">
                <list>
                    <bean
                       
class="org.apache.cxf.aegis.databinding.XFireCompatibilityServiceConfiguration"
/>
                    <bean
class="org.apache.cxf.service.factory.DefaultServiceConfiguration" />
                </list>
            </property>
        </bean>
    </simple:serviceFactory>
</simple:server>

Please advise if there was a better (less verbose ?) way to do it.

The above solve the qualification of parameters problems, and absence of the
"/" at the end of the namespace in XFire.

Next big problem was the name of the default parameters and return values
for the operations. This is how I solved it, but I thought it would be a lot
better if it is integrated into CXF :


//----------------------------------------------------------------
//MyXFireCompatibilityService.java
//----------------------------------------------------------------
package test.compatibility;

import java.lang.reflect.Method;

import javax.xml.namespace.QName;

import org.apache.cxf.service.factory.DefaultServiceConfiguration;
import org.apache.cxf.service.factory.ServiceConstructionException;
import org.apache.cxf.service.model.OperationInfo;

public class MyXFireCompatibilityService extends DefaultServiceConfiguration
{

    public MyXFireCompatibilityService() {
        
    }
    
    @Override
    public QName getInParameterName(OperationInfo op, Method method, int
paramNumber) {
        return new QName(op.getName().getNamespaceURI(), 
                         getDefaultLocalName(op, method, paramNumber,
"in"));
    }

    @Override
    public QName getOutParameterName(OperationInfo op, Method method, int
paramNumber) {
        return new QName(op.getName().getNamespaceURI(), 
                         getDefaultLocalName(op, method, paramNumber,
"out"));
    }

    private String getDefaultLocalName(OperationInfo op, Method method, int
paramNumber, String prefix) {
        Class<?> impl = getServiceFactory().getServiceClass();
        // try to grab the implementation class so we can read the debug
symbols from it
        if (impl != null) {
            try {
                method = impl.getMethod(method.getName(),
method.getParameterTypes());
            } catch (Exception e) {
                throw new ServiceConstructionException(e);
            }
        }
        
        return DefaultServiceConfiguration.createName(method, paramNumber,
op.getInput()
            .getMessageParts().size(), false, prefix);
    }
//----------------------------------------------------------------


...And just replace the DefaultServiceConfiguration with this class in the
above xml configuration file.
Looks like it is working. I'd appreciate some confirmation on this.

Please note that :
1) I had to cut and paste getDefaultLocalName(), because the method is
private => maybe you CXF guys could make it protected...?
2) The only method in the (existing) XFireCompatibilityServiceConfiguration
could easily be added in the above class so we have to add only one service
configuration

What remains after these is some not-too-important differences about the
minOccurs and the nillable attributes in the schema, that should be quite
easily changeable in the same way as I changed default parameters names.


-- 
View this message in context: http://old.nabble.com/XFire-migration---old-client-doesn%27t-send-named-parameters-tp22482409p28328837.html
Sent from the cxf-user mailing list archive at Nabble.com.


RE: XFire migration - old client doesn't send named parameters

Posted by Kevin Priebe <ke...@realtyserver.com>.
Thanks for the info Dan.  That does sound like a better solution than what I
had working before.  I had actually started writing an Interceptor last
night because I realized that with the Servlet transport I can detect if
user-agent contains 'XFire' and then do some funky stuff with the message
before it is unmarshalled.  That way it won't affect performance for
requests coming from CXF clients.  Unfortunately the 'funky stuff' part is
where I am at now and am a little lost.  I'm currently looking at a few of
the other interceptors to see what they do and hopefully I can figure it
out.  Any tips on how to get started with wrapping a XMLStreamReader and
what interceptor phase to do this in (RECEIVE, *_STREAM)?  Are there any
interceptors that do something similar that I should look at?  I know how
I'll find the proper parameter names etc., but am unfamiliar with how the
overall process should be done.  Thanks for the help,

Kevin


-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org] 
Sent: March-13-09 12:06 PM
To: users@cxf.apache.org
Cc: Kevin Priebe
Subject: Re: XFire migration - old client doesn't send named parameters


CXF is pretty strict about matching the messages up with the schema.  If
they 
don't match, it really won't find the correct parts and deserialize things.

That's what you are seeing.   "in0 != board"

The only option is to write a "filter/mapper" that would map the incoming
data 
into the data that does match the schema.   The most performant way to do
that 
would be to write a XMLStreamReader that wrappers the original
XMLStreamReader 
and whenever the token is start element or similar, map the element names.

An interceptor would just need to put your reader in place.

Dan


On Thu March 12 2009 2:10:41 pm Kevin Priebe 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></n
>s 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.XFireCompatibilityServiceConfigurat
>i 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

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog


Re: XFire migration - old client doesn't send named parameters

Posted by Daniel Kulp <dk...@apache.org>.
CXF is pretty strict about matching the messages up with the schema.  If they 
don't match, it really won't find the correct parts and deserialize things.  
That's what you are seeing.   "in0 != board"

The only option is to write a "filter/mapper" that would map the incoming data 
into the data that does match the schema.   The most performant way to do that 
would be to write a XMLStreamReader that wrappers the original XMLStreamReader 
and whenever the token is start element or similar, map the element names.    
An interceptor would just need to put your reader in place.

Dan


On Thu March 12 2009 2:10:41 pm Kevin Priebe 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></n
>s 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.XFireCompatibilityServiceConfigurat
>i 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

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog