I like to make use of the builder pattern whenever an object has both mandatory and optional properties. But building objects is usually the Spring framework responsibility, so let’s see how you can employ it using both Java and XML-based Spring configurations.
Continue reading “The Builder pattern and the Spring framework”
Spring framework is widely used as a dependency injection container, and that’s for good reasons. First of all, it facilitates integration testing and it gives us the power of customizing bean creation and initialization (e.g. @Autowired for List types).
But there is also a very useful feature, that might get overlooked and therefore let’s discuss about bean aliasing.
Bean aliasing allows us to override already configured beans and to substitute them with a different object definition. This is most useful when the bean definitions are inherited from an external resource, which is out of our control.
In the following example, I will show you how bean aliasing works. Let’s start with the following bean definition, coming from the src/main/resources/spring/applicationContext-tx.xml configuration file.
Continue reading “Why I like Spring bean aliasing”
Spring Framework dependency injection is great, and almost every Java developer uses it nowadays. Using @Autowired to inject Java Beans is trivial, but we can also use this annotation for
java.util.Map as well. The former will inject a list of all Java Beans matching the List’s Generic type, while the latter will create a map of these beans mapped by their names.
How I’ve been taking advantage of this feature?
Since I was developing an application which has a framework module and a specific customer implementation module, there were cases where I needed to add a common logic in the framework module which would detect all Beans of a given type, even the ones defined in the specific module.
Continue reading “Why I like Spring @Autowired for List types”