Understood.
In order to keep a consistent (ie. reusable) configuration for the transport I
have done the following:
Created a file parallel to my services.xml file called transports.xml. This new
file looks something like this:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:jee="http://www.springframework.org/schema/jee";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
">
<bean class="org.codehaus.xfire.spring.config.XFireBean">
<property name="transports">
<bean class="org.codehaus.xfire.transport.jms.JMSTransport">
<constructor-arg ref="xfire"/>
<constructor-arg ref="wlConnectionFactory"/>
</bean>
</property>
</bean>
</beans>
I then added the following line to the top of my services.xml:
<import resource="transports.xml"/>
This works on the server side.
On the client side I added transports.xml to the list of files to import into
my root spring context.
I also wrote up the proxy bean as follows (in a client.xml file):
<bean id="EchoServiceJmsClient"
class="com.xyz.xfire.spring.remoting.XFireClientFactoryBean">
<property name="endpoint">
<bean class="javax.xml.namespace.QName">
<constructor-arg value="http://xyz.com/Echo"/>
<constructor-arg value="EchoJMSEndpoint"/>
</bean>
</property>
<property name="XFire" ref="xfire"/>
<property name="serviceFactory" ref="xfire.serviceFactory"/>
<property name="serviceInterface"
value="com.xyz.service.echo.EchoService"/>
<property name="wsdlDocumentUrl"
value="http://localhost:8081/echo-service/services/Echo?wsdl"/>
</bean>
I had to modify the XFireClientFactoryBean so that I could pass in the instance
of XFire from my app context for the calls new XFireProxyFactory() on lines 551
and 571 so that the transport configuration would show up.
I currently have this working for HTTP but not JMS. I think the change
necessary is related to anonymous endpoints not working for JMS (for which
there is a simple fix, but I haven't added it yet).
I'll update you as a get further along. Any suggestions are welcome.
Sam
PS. I also have mostly working code to replace the custom JMS code in
XFire with the Spring JMS code. This includes an integration with the
spring ListenerContainer. Perhaps I could somehow get this contributed
to the xfire codebase somehow?
Fried Hoeben wrote:
Sam,
This proxy factory will only work for connecting over HTTP.
Have you tried just setting the WSDL url for your service, and the service
class? (That should work if you're using Aegis. Otherwise you'll also have to
configure a different ServiceFactory, and maybe a few other things)
The services.xml is not relevant for clients, as far as I know.
Normally this proxy can determine the correct end point, and URL, based on the
WSDL content.
Fried
-----Original Message-----
From: Sam Wilson [mailto:[EMAIL PROTECTED]
Sent: Fri 2/2/2007 10:26 PM
To: [email protected]
Subject: [xfire-user] Spring Remoting client to service with multiple endpoints.
All,
I have successfully configured a service with multiple endpoints (http,
jms) and would now like to configure my client using the spring remoting
feature using XFireClientFactoryBean.
However, it's a little unclear to me how to specify this. Should I be
specifying the endpoint (setEndpoint) or simply provide the appropriate
URL (setURL) and let XFire figure out which endpoint to target?
When I use the setURL approach I get an exception indicating that there
is no transport registered for the URL, though I am using the same
services.xml config file as the server side, which is working fine.
When I set the endpoint, I'm not really sure what value to pass in. I've
tried a number of different values with no success.
Any ideas? How do you guys normally configure for such a scenario? Does
the XFireClientFactoryBean make sense here, or should a different
approach be taken?
Thanks,
Sam Wilson
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
