Konubinix' opinionated web of thoughts

IoC Container

Fleeting

Table 5.2. Autowiring modes

Mode Explanation
no (Default) No autowiring. Bean references must be defined via a ref element. Changing the default setting is not recommended for larger deployments, because specifying collaborators explicitly gives greater control and clarity. To some extent, it documents the structure of a system.

Are annotations better than XML for configuring Spring?

The introduction of annotation-based configurations raised the question of whether this approach is ‘better’ than XML. The short answer is it depends. The long answer is that each approach has its pros and cons, and usually it is up to the developer to decide which strategy suits her better. Due to the way they are defined, annotations provide a lot of context in their declaration, leading to shorter and more concise configuration. However, XML excels at wiring up components without touching their source code or recompiling them. Some developers prefer having the wiring close to the source while others argue that annotated classes are no longer POJOs and, furthermore, that the configuration becomes decentralized and harder to control.

No matter the choice, Spring can accommodate both styles and even mix them together. It’s worth pointing out that through its JavaConfig option, Spring allows annotations to be used in a non-invasive way, without touching the target components source code and that in terms of tooling, all configuration styles are supported by the SpringSource Tool Suite.

Full @Configuration vs ’lite’ @Beans mode?

When @Bean methods are declared within classes that are not annotated with @Configuration they are referred to as being processed in a ’lite’ mode. For example, bean methods declared in a @Component or even in a plain old class will be considered ’lite’.

Unlike full @Configuration, lite @Bean methods cannot easily declare inter-bean dependencies. Usually one @Bean method should not invoke another @Bean method when operating in ’lite’ mode.

Only using @Bean methods within @Configuration classes is a recommended approach of ensuring that ‘full’ mode is always used. This will prevent the same @Bean method from accidentally being invoked multiple times and helps to reduce subtle bugs that can be hard to track down when operating in ’lite’ mode.

The @Bean annotation is used to indicate that a method instantiates, configures and initializes a new object to be managed by the Spring IoC container.

@Configuration is a class-level annotation indicating that an object is a source of bean definitions. @Configuration classes declare beans via public @Bean annotated methods. Calls to @Bean methods on @Configuration classes can also be used to define inter-bean dependencies. See Section 5.12.1, “Basic concepts: @Bean and @Configuration” for a general introduction.

All @Configuration classes are subclassed at startup-time with CGLIB. In the subclass, the child method checks the container first for any cached (scoped) beans before it calls the parent method and creates a new instance.

Remember that @Configuration classes are ultimately just another bean in the container - this means that they can take advantage of @Autowired injection metadata just like any other bean!

Remember that @Configuration classes are ultimately just bean definitions in the container.

Notes linking here