Spring best practices and guidelines

[Zinno1973]

Category: Spring core - configuration
Argumentation:

• It saves typing.

I would not recommend using auto wiring in large projects. The chances of unexpected behavior increases and it makes the xml files more difficult to read/understand.

[karldmoore]

Useful one.

Specifying the target bean by using the local attribute leverages the ability of the XML parser to validate XML id references within the same file. The value of the local attribute must be the same as the id attribute of the target bean. The XML parser will issue an error if no matching element is found in the same file. As such, using the local variant is the best choice (in order to know about errors are early as possible) if the target bean is in the same XML file.

[Ward Bergmans]

Is there any best practice on using aliases for switching between different environments?

Introduction about our situation:
We've got these environments:
- Lokaal (Local Developers Machine)
- Ontwikkel (Development)
- Test (Test ;-))
- Acceptatie (Acceptation)
- Productie (Production)

Our configuration for O, T, A, and P is the same. The configuration for the Local developers machine is different from OTAP.

We use CVS as our source code version system.

We use Maven 1.0.2 as our build tool.


Our best practice:
If the configuration is the same for all the environments except for the developers machine, then
make (a) separate configuration file(s) with the configuration that is different.
Let this different configuration overwrite the definition(s) in the original file(s).
Make sure this different configuration will never be placed in the other environments!!!

Example of how to achieve this if you use the org.springframework.context.support.ClassPathXmlAp plicationContext:

Note: I give every example file below a unique name, so I can easily refer to it.

Contents of beanRefContext.xml:

<beans>
<bean id="aBeanId" class="org.springframework.context.support.ClassPa thXmlApplicationContext">
<constructor-arg>
<list>
<value>/spring/applicationContext-forAllTheEnvironments.xml</value>
<value>/spring/applicationContext-local.xml</value>
</list>
</constructor-arg>
<constructor-arg>
<ref bean="frameworkApplicationContextId"/>
</constructor-arg>
</bean>
</beans>


Some explanation: Beans defined in the config locations (first constructor-arg) overwrite the beans in the parent application context (second constructor-arg).
Quote from the JavaDoc of this class "In case of multiple config locations, later bean definitions will override ones defined in earlier loaded files. This can be leveraged to deliberately override certain bean definitions via an extra XML file."

This way you can overwrite bean definitions by placing them in applicationContext-local.xml.

Contents of the file applicationContext-local.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<description>
This configuration contains overrides beans and aliases to test the application locally on the developers machine.
This configuration should never be placed in production.
</description>

<!-- In memory DAO's configuration -->
<alias alias="blogEntryDao" name="blogEntryDaoMemory" />
<alias alias="referralDao" name="referralDaoMemory" />


<bean id="managementInfoBean" class="x.y.mockup.ManagementInfoMockup">
<description>
Bean override of the managementInfoBean with a mockup to be able to test locally.
</description>
</bean>
</beans>


applicationContext-local.xml will overwrite the blogEntryDao and referralDao bean with in memory Dao’s and it will overwrite the managementInfoBean with a Mockup.


To make sure applicationContext-local.xml is excluded from the build you need to add a exclude resource to the Maven project.xml build tag.

Contents of Maven 1.0.2 project.xml:

<!-- I left out the first part of the project.xml file contents -->
<resources>
<resource>
<directory>${basedir}src/main/resources</directory>
<includes>
<include>*.*</include>
<include>**/*.*</include>
</includes>
<excludes>
<exclude>.*</exclude>
<exclude>spring/applicationContext-local.xml</exclude>
</excludes>
<filtering>false</filtering>
</resource>
</resources>
</build>
</project>


Before beanRefContext.xml is committed to CVS "<value>/spring/applicationContext-local.xml</value>" should be removed. But if you forget, there is no problem. If Spring can't find the /spring/applicationContext-local.xml file, Spring doesn't halt. (strange enough Spring doesn't even give an error message). And because /spring/applicationContext-local.xml is excluded from our build Spring can't find it. So this local test configuration will never get into the other environments.

Category: Spring core – configuration

Argumentation:

• If you use the following solution to change the configuration to test locally: Comment out bean definitions in the original configuration file and replace them with bean definitions to test locally. Then you will get the following problems:
  
  • You can accidentally place the configuration with the modifications to test locally in CVS. This causes bugs in the environments where this application is deployed.
    
  • Configuration files will get longer and harder to read and maintain.
    
  • It isn’t easy to comment out configuration parts that have comments in them.
    

[manifoldronin]

Don’t place all your beans in one xml file (in large applications).
Split the configuration in different xml files. Minimal one xml file per architectural layer.

Category: Spring core – configuration

Argumentation:

• Long xml files are hard to read.

Mmm... we definitely don't want to keep all beans in one file, but I am not sure about breaking down between the service and data access tiers - for the same reasons I don't usually recommend defining Java packages like 'model','service', or 'dao'. Here, in particular, by keeping a service bean and its dao(s) in separate files, you lose the ability to reference by id, and hence the built-in XML validation. Also it's harder to trace the dependencies between beans.

Again similar to packaging, my preference would be to split along logical functionality groups. In other words, I see more reason for UserDAO than for ProductDAO to be in the same XML with UserService.

All that being said, I do keep all the view definitions separated from the "backend" tiers - so that's indeed some horizontal break-down between the presentation and business tiers. Firstly it's due to that Spring MFC has its own way of loading servlet specific contexts. Secondly it makes it easier to support various deployment schemes and view technologies. (Neither of those applies to the case between service and data access).

[sabarish]

Here, in particular, by keeping a service bean and its dao(s) in separate files, you lose the ability to reference by id, and hence the built-in XML validation. Also it's harder to trace the dependencies between beans.

+1. As you have noted, this makes sense for java packages too.

[Jörg Heinicke]

But especially for the packages I like the separation in layers.
You can assure that nothing relies on implementation details (as long as you don't make it public).

Jörg

[laenzlinger]

But especially for the packages I like the separation in layers.
You can assure that nothing relies on implementation details (as long as you don't make it public).

Hi Jörg,

What do you mean exactly? Do you propose to put the classes for each layer into a separate package like in the jpetstore sample?

I used this approach before and put the the corresponding bean definitions into the classpath close to those classes - with the disadvantages mentioned below.

Both organisations have advantages and disadvantages, depending on what level of (de-)coupling you want to achieve. For example if you need to provide different data-access implementations it might be better to have the data-access layer in a separate file so that it is easier to can exange it.

On the other hand if it is more important to deliver complete sub-components along functional borders it might be better to keep the whole component defintion together.

[Jörg Heinicke]

What do you mean exactly? Do you propose to put the classes for each layer into a separate package like in the jpetstore sample?

That was only meant on the Java packages level without considering Spring configs at all. I have exactly the packages 'model', 'service' and 'dao' as mentioned by manifoldronin.

I wonder how often it's possible to 'deliver complete sub-components along functional borders'. At least for my applications there is rarely a 1:1-relationship between classes in the different layers. This seems to be mostly only the case for pure CRUD, doesn't it?

Regards
Jörg

[Ward Bergmans]

Use parent bean if the same values must be injected in multiple beans, or if it saves typing.

Category: Spring core – configuration

A child bean definition is a bean definition which inherits configuration data from a parent definition.

A parent bean definition is a "template" with configuration information that can be inherited. The parent bean can be marked abstract (with abstract="true") to prevent it from being instantiated.

See the Spring Reference Manual, paragraph 3.6. Bean definition inheritance for more information.

Example of bean definition inheritance:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<description>
Spring Web MVC Dispatcher Servlet configuration.
</description>

<!-- *********************** -->
<!-- Application controllers -->
<!-- *********************** -->

<!-- abstract parent bean with configuration that needs to be the same for all the controllers -->
<bean id="abstractController" abstract="true">
<property name="blogService" ref="blogService" />
<property name="administrationService" ref="administrationService" />
</bean>

<bean id="overviewController" name="/overview.htm" parent="abstractController" class="x.y.z.web.controllers.OverviewController">
<property name="viewName" value="overview" />
</bean>

<bean id="showController" name="/show.htm" parent="abstractController" class="x.y.z.web.controllers.ShowBlogEntryControll er">
<property name="viewName" value="show" />
</bean>

<!-- The add and edit controller -->
<bean id="addAndEditController" name="/edit.htm" parent="abstractController" class="x.y.z.web.controllers.AddAndEditController" >
<property name="formView" value="edit" />
<property name="successView" value="redirect:overview.htm" />
<property name="validator">
<bean class="x.y.z.validators.BlogEntryValidator" />
</property>
</bean>

<bean id="saveController" name="/save.htm" parent="abstractController" class="x.y.z.web.controllers.SaveController">
<property name="viewName" value="save" />
</bean>

<!-- The DeleteBlogEntryController is a ThrowAwayController, there singleton needs to be "false" -->
<bean name="/delete.htm" parent="abstractController" class="x.y.z.web.controllers.DeleteBlogEntryContro ller" singleton="false" />

<bean id="rssController" name="/rss.htm" parent="abstractController" class="x.y.z.web.controllers.RSSController">
<property name="view" ref="rssView" />
</bean>

<bean id="pdfController" name="/showPDF.htm" parent="abstractController" class="x.y.z.web.controllers.PdfController">
<property name="view" ref="pdfView" />
</bean>

<!-- ...I left out the rest of the content of my configuration file. The above is (more than) enough to demonstrate bean definition inheritance ... -->


Argumentation:

• If all beans must have the same values injected and the values change, then you only have to change the parent bean definition. This way all the child beans (that don’t overwrite a value) will have the new values. This saves typing and prevents errors (like forgetting to change the values for one bean.)
• If you got a list of property value pairs that are injected in a lot of beans, then you will get long configuration files (which are hard to read). Bean inheritance can prevent this.
• Writing the same property value pairs over and over again takes time. With bean inheritance this time can be reduced.
• Templating prevents configuration duplication. Duplication - whether in configuration or code - is bad and should be minimized.

[karldmoore]

Templating beans can be very useful, this was true pre 2.0 with a TransactionProxyFactoryBean.