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. ;-)
Comments (9) |
del.icio.us
| 
Digg It!
| 
Linking Blogs
| 4386 Views
# Posted By Andy Jarrett | 5/19/08 12:20 PM
Nice extension Brian, I'll this to the post!
# Posted By Dan Wilson | 5/19/08 12:58 PM
Based on what you've said above, I am not doing it the most efficient way so I'm interested in hearing more about extending ColdSpring for remote work.
Please, Blog On Brian!
DW
# Posted By Daniel Schmid | 5/20/08 3:37 AM
I'm just working on a flash remoting frontend applicatiion, thus I would love to read more how to use CS best in this environment.
# Posted By Henry | 5/21/08 10:45 AM
I used remote facade before, but I hate how CFC Explorer doesn't work on the generated CFC....
# Posted By Brian Kotek | 5/21/08 12:30 PM
Since the Remote Proxies are actually written to disk, there is no reason why the CFC Explorer won't handle them. But more to the point: why do you care? The Remote Proxies are just that, proxies for real CFCs. I would think you'd just view the underlying CFC instead of caring what the Remote Proxy looks like?
# Posted By Henry | 5/21/08 12:37 PM
I had a situation where my team member would rely on my remote proxy to work with my subsystem, but I couldn't point him to use CFC Explorer. I was using CF8 at the time, and somehow the cfc explorer wouldn't work.
One more thing, My Ajax controls relied on the remote proxy, but I couldn't use the new arguments available to CF8 in the generated CFFUNCTION like verifyClient.
# Posted By Brian Kotek | 5/21/08 12:53 PM
Looks like you're right, due to the fact that the CFC Explorer tries to instantiate the component. You can try using the CFC Documentation Generator at RIAForge (http://cfcdoc.riaforge.org) which appears to work.
# Posted By Elliott Sprehn | 8/25/08 1:57 AM
@Brian
I'm looking through the code to ColdSpring and it doesn't seem the constructNonLazyBeans argument actually does anything.
CS always constructs the non-lazy beans even if you don't specify the argument.
There is an argument to processLoadBeans() called constructNonLazyBeans which defaults to false, but the function doesn't check it and just always calls initNonLazyBeans(). None of the loadBeansFrom* or loadBeans methods pass the constructNonLazyBeans argument to the processLoadBeans() function either.
# Posted By Brian Kotek | 8/25/08 12:43 PM
Elliott, you're right. It looks like the constructNonLazyBeans argument has essentially been deprecated. To be honest I never saw much point to it anyway. If the XML already declares a bean to be non-lazy, why should one have to also manually tell ColdSpring to create them on startup?