Spring best practices and guidelines

[karldmoore]

A general best practice for any problems is, "read the reference manual". So many of the simple questions can be answered by having a quick thumb through it. We are ALL still learning and obviously there are times you can't find the answer in there, but atleast give it a go! Please .

[Draw]

Always use auto-wiring.

My best practice is the opposite:
Always use explicit wiring.

Argumentation:

• Application works as configured. It does nothing more than you’ve configured and nothing less. You can see how it is configured (nothing magical happens.)
• Auto-wiring is less self-documenting than explicit wiring.
• With auto-wiring by name the renaming of bean or property names easier leads to errors than with the use of explicit wiring.
• Auto-wiring by name may lead to artificial property names. (So that you can take advantage of the auto-wiring functionality.)
• With auto-wiring by type you can only have one bean of a certain type in your configuration. For example, if there are two DataSources, auto-wiring by type will not work.

[karldmoore]

Personally, I don't use it. I agree with a lot of your points. The few times I have used it, people really didn't like it. They wanted to know where the beans were coming from. As I said previously, I'm glad its there, but it is voodoo.

[debasishg]

My best practice is the opposite:
Always use explicit wiring.

Argumentation:

• Application works as configured. It does nothing more than you’ve configured and nothing less. You can see how it is configured (nothing magical happens.)
• Auto-wiring is less self-documenting than explicit wiring.
• With auto-wiring by name the renaming of bean or property names easier leads to errors than with the use of explicit wiring.
• Auto-wiring by name may lead to artificial property names. (So that you can take advantage of the auto-wiring functionality.)
• With auto-wiring by type you can only have one bean of a certain type in your configuration. For example, if there are two DataSources, auto-wiring by type will not work.

+1 on your auto-wiring thoughts. I have also generally observed clients do not like the terseness of auto-wiring. I support your call for using explicit wiring.

- Debasish

[Ward Bergmans]

Place Spring configuration files in a standard location.

For example:

• For a jar in:
  src/main/resources/spring
  
• For test about a jar in:
  src/test/resources/spring
  
• For a war in:
  WEB-INF/spring
  
• For test about a war in:
  WEB-INF/spring

Category: Spring core – configuration

Argumentation:

• This makes applications consistent.

[Ward Bergmans]

Use the following naming convention for configuration filenames: applicationContext-<a describing name>.xml

Category: Spring core – configuration

Argumentation:

• A naming convention makes applications consistent.
• This naming convention is used in the Spring sample applications.

Question:
Do you have another naming convention? Please let me know which one.

[Ward Bergmans]

Give beans describing names.

Category: Spring core – configuration

Argumentation:

• Describing bean names makes the configuration easier to understand and maintain.
• To limit the risk of an accidental bean overwrite.
  A short true story:
  A project used XFire. (XFire is a SOAP framework with Spring support, see http://xfire.codehaus.org/ for more information). The project named a bean of the type org.springframework.beans.factory.config.CustomEdi torConfigurer CustomEditorConfigurer. They got weird errors. The reason of these errors was… XFire also named a bean CustomEditorConfigurer. And this XFire CustomEditorConfigurer bean had overwritten the CustomEditorConfigurer bean of the project.

[Ward Bergmans]

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

Place the parts of your configuration that may change in different environments in (a) separate xml file(s).

Make a version of this file for every different environment. (And give this file a describing name ;-).)

Category: Spring core – configuration

Argumentation:

• Then the configuration part that doesn’t change in different environments is guaranteed not to change. So the bulk of your configuration can be tested outside the eventual deployment environment.
• The separation makes clear which parts of the configuration change over the different environments. So which parts need special test attention after the application is deployed in a new environment.
• If you make configurations for every different environment with all the beans (those beans that change and those that stay the same) in it, then you get configuration duplication. The beans that stay the same will be defined in all the configuration files for the different environments.
• If you make one configuration file with the configuration for every different environment and comment out the configuration parts that you don’t need in that environment, then you will get the following problems:
  
  • If you have this situation: you comment out the configuration for the other environments and uncomment the configuration to test locally. You start coding new functionality. You edit the configuration for this new functionality. You code a little more till everything works.
    Then you synchronize your code with the versioning system. You don’t check in your configuration, because you don’t want to commit the changes that you’ve made to test locally ...but you forgot that the configuration also had changes to make the new functionality working. You build and deploy your application. And you’ve got a bug...
    Or:
    Then you synchronize your code with the versioning system. You check in all the modified files. ...but you forgot that the configuration file contains the configuration to test locally instead of the original configuration. You build and deploy your application. And you’ve got a bug...
    
  • Configuration files will get very long and hard to read and maintain.
    
  • It isn’t easy to comment out configuration parts that have comments in them.
    

[Ward Bergmans]

Place configuration that can be different on another developers machine in (a) separate configuration file(s).

Give these files a describing name, so it’s clear to another developer that he may need to change this file to make the application work locally.

Document how others have to edit the configuration to make everything working on their system.

For example:
Contents of user-dependent-configuration.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 Spring configuration contains user dependent data.
For example usernames and passwords.
So you (may) need to edit this file to get a proper configuration.
</description>

<bean id="databaseUsernameAndPassword" abstract="true">
<description>
org.springframework.jdbc.datasource.DriverManagerD ataSource
template.
This template specifies your database username and password.
</description>
<property name="username" value="type_your_username_here"/>
<property name="password" value="type_your_password_here"/>
</bean>
</beans>

Category: Spring core – configuration

Argumentation:

• If you would not place this user dependent configuration in a separate file, then this can happen:
  
  1. Developer 1 checks out code from the versioning system.
     
  2. Developer 1 changes the user dependent part of the configuration to be able to test the application locally.
     
  3. Developer 1 starts coding. And after a while he adds something to the configuration. He does some more coding. And all the test succeed :-)
     
  4. Developer 1 checks in all the code and configuration (including the user dependent part).
     
  5. Developer 2 synchronizes his code.
     
  6. Developer 2 will get a merge conflict on the configuration file.
     
  
  This causes the following problems:
  
  • Time is wasted, because merge conflicts need to be solved.
    
  • It can easier happen that the user dependent configuration of a certain developer gets checked in the versioning system. And all the “type_your_data_here” notes will be overwritten.
    
  
  
  Even worse, this can happen:
  
  • Steps 1-3 from above are preformed.
  • Developer 1 checks in all the code, but he doesn’t check in the configuration, because he thinks “that file contains my user dependent configuration. I don’t want to place that in the versioning system, so I skip that file”
    
  
  This causes the following problems:
  
  • The new configuration part isn’t backed up in the versioning system.
    
  • The application won’t work anymore, because the new part of the configuration is missing.
    

[karldmoore]

I wouldn't agree with this, I would use a PropertyPlaceholderConfigurer and move the configuration out to a properties file. You can also then tell the configurer that if the value can't be resolved to throw an exception.

public void setIgnoreUnresolvablePlaceholders(boolean ignoreUnresolvablePlaceholders)
Set whether to ignore unresolvable placeholders. Default is "false": An exception will be thrown if a placeholder cannot be resolved.

http://static.springframework.org/sp...olders(boolean)