Skip to content

Advanced Spring configuration

Drivers

  • The generated artifact should be the same regardless of the target environment. This means that any deployment configuration must be run-time, not build-time.
  • Keep configuration as close to the bean that needs it as possible. Self-configuring beans should be preferred.
  • Minimize the number of properties that must be set in property files.
  • Allow full flexibility to override parameters for tweaking the application.
  • Staging: Support switching implementations of a service to facilitate development, test and production environments.

Challenges

  • Switch resources run-time (e.g. datasource)
  • Switch implementations (e.g. to facilitate staging)
  • Authentication and authorization (e.g. username and password to a database)
  • Let system administrators customize and tweak the application
  • Two or more beans share a property (code smell?)
  • How to ensure that required properties are set correctly?
  • Readability: It should be easy to see
    • a) which implementations are used and
    • b) how these are configured.

Extra Challenges

While out of scope; Does the different tactics make it easier or harder to implement a configuration management strategy? Distributed systems, robustness and reliability are keywords here.

Solutions

There are two approaches currently available to solve these challenges; - Use a combination of PropertyPlaceholderConfigurer, PropertyOverrideConfigurer, Factory-bean and Maven profiles: - Classic Spring configuration tactics - Deploy to different environments - run-time - Use Staged Spring

Currently Staged Spring seem to be a much better solution than the classic tactics. There are however a couple of issues that must be addressed to make it enticing also for system administrators. See ticket 1 and ticket 3.