More on ColdSpring and Remote Facades

The first bit is just a small change that makes life easier. In Andy's example, he defines the remote proxy in his ColdSpring XML file and then manually calls getBean() to create that remote proxy. You actually can do this in an easier way, using the lazy-init attribute and the constructNonLazyBeans argument. If you pass "constructNonLazyBeans=true" as an argument to loadBeansFromXML, ColdSpring will automatically create any beans that you have not explicitly marked as lazy. Which means you can avoid having to manually call getBean() for all of your remote proxies. You just need to execute one initial request to your application, and it will create the remote proxies automatically. This is handy if you start having numerous remote proxies being generated.

Next is a small tip to make your configuration life a little easier. Andy shows the XML to define a remote proxy. It's fairly verbose XML, unfortunately. That's just how ColdSpring is. However, we could make life a bit easier on ourselves by defining a parent bean and setting common values there. Again, this makes life easier once you start getting into multiple remote proxies. You can do something like this:

<bean id="abstractRemoteProxy" class="" abstract="true">
	<property name="beanFactoryScope">
		<value>application</value>
	</property>      
	<property name="beanFactoryName">
		<value>beanFactory</value>
	</property>   
	<!--- location to the physical proxy component --->
	<property name="relativePath">
		<value>/remote_cs</value>
	</property>
</bean>

<bean id="userServices_remote" class="coldspring.aop.framework.RemoteFactoryBean" parent="abstractRemoteProxy" lazy-init="false">
	<property name="target">
		<ref bean="userServices" />
	</property>
	<!--- Physical name given to the proxy component --->
	<property name="serviceName">
		<value>rUserServices</value>
	</property>
	<!--- you could have something like get* for all get methods only --->
	<property name="remoteMethodNames">
		<value>*</value>
	</property>
</bean>

		

As you can see, assuming you are OK with having the same bean factory name, having the remote proxies be created in one central folder, etc., you can cut down the amount of XML you have to write per-proxy by a lot.

And one last time, don't forget that you can extend the base RemoteFactoryBean and ProxyFactoryBean components that ColdSpring uses to define your own custom behavior. This can reduce work even more by letting you skip a lot of the XML entirely and define settings or behavior directly in your custom Factory Bean. I can expand on this if anyone wants to hear more, I'm just not sure how many people are actually using these parts of ColdSpring so I thought I would ask before I launch into a blog entry that no one cares about. ;-)