ColdSpring Bean Properties

In the ColdSpring in 5 Minutes example, you saw how you can use the XML attribute 'default-autowire="byName"' to tell ColdSpring to try and resolve the dependencies in your components automatically. However, if your setter method names don't all match your ColdSpring beanID values, or if you prefer to have a more explicit description of the dependencies, you can explicitly define properties for your ColdSpring beans.

When The Heck is a Bean?

It's probably time we covered this since we'll be using the term more and more. Since ColdSpring is a port of the Spring framework for Java, it has adopted many of its naming conventions for consistency. One of these is the idea of a "bean".

Simply put, a bean is a CFC that has getters and setters for its properties. That's all. So that means if we have a UserGateway that has an instance variable named "configBean", that the CFC also has a setConfigBean() and getConfigBean() method. There's nothing more to it than that. If a CFC has getter and setter methods for its properties, it's a bean.

If we wanted to use bean properties to define a dependency in the ColdSpring XML configuration file, we would do it like this:

<bean id="userGateway" class="coldspring.examples.quickstart.components.UserGateway">
	<property name="configBean">
		<ref bean="configBean" />

With that XML, ColdSpring knows that there is a property on the UserGateway named "configBean". So we're telling it to call "setConfigBean()" and pass in our ConfigBean CFC.

Why Would I Specify Bean Properties Instead of Using the Automatic Autowiring?

Some people might wonder why one would take the extra step of manually defining the dependencies instead of letting ColdSpring work its magic with "default-autowire". There are actually a few reasons one might do this.

First, as we noted, your setter names may not line up exactly with your beanIDs. In cases like that, ColdSpring can't guess, so you have to tell it how to handle the dependency.

Second, many developers actually find a large benefit to having the dependencies between their CFCs explicitly defined in one place. If you define the dependencies yourself, your ColdSpring XML becomes a very useful "map" of your components and what they depend on. Without this, knowing what depends on what can become rather murky and require opening up individual CFCs to look for setter methods and figure out what the dependencies are.

Third, there is a certain amount of, shall we say, danger, in just letting ColdSpring run riot through your CFCs and autowire every setter that happens to have a matching beanID. You may very well not want it to do this! If a CFC happens to have a setConfig() method that you use for something unrelated to another CFC, but there also happens to be a bean with an ID of "config", you might see the problem. With 'default-autowire="true"' set globally in your XML, ColdSpring will try to handle this dependency whether you want it to or not.

Keep in mind that you have the flexibility to mix and match the autowiring feature if you choose to. For example, you could set 'default-autowire="byName"' in your root beans XML element, but then override that setting on individual beans where you need to specify a dependency explicitly:


<beans default-autowire="byName">
	<bean id="userService" class="coldspring.examples.quickstart.components.UserService" />
	<bean id="userGateway" autowire="no" class="coldspring.examples.quickstart.components.UserGateway">
		<property name="configBean">
			<ref bean="configBean" />
	<bean id="configBean" class="coldspring.examples.quickstart.components.ConfigBean" />

Which gives you the flexibility to specify dependencies explicitly if you need to, but leverage the automatic autowiring if you choose to.