Questions:
1) Difference between @Component
and @Configuration
?
I have read that both remove the necessity of
In most the answers above, users suggest to say that @Component and @ Configuration serve different purposes. But I do not see it happening in reality.
But I have a simple Spring MVC application.
@Configuration
public class SpringConfiguration {
@Bean
public InternalResourceViewResolver initViewResolver(){
InternalResourceViewResolver x = new InternalResourceViewResolver();
x.setPrefix("/WEB-INF/jsp/");
x.setSuffix(".jsp");
return x;
}
}
This main class works fine even if it is annotated as @Component instead of @Configuration.
Similarly inside a class annotated as @Component if you have methods annotated with @Bean, those beans are created when context is loaed.
So I think, it is just for code readability that we should mark main configuration class as @Configuration and other classes with @Component. Actual execution wise there seems no difference.
1) If you want XML configuration, then ignore @Configuration, as this is only useful for Java-based config. XML config is probably best for someone unfamiliar with Spring as there are more examples available.
@Component annotated classes are picked up during component scanning. Use them to label classes that you want to expose as Spring beans. Again, you can just declare all of your beans in the XML config and ignore @Component altogether.
2) If you are happy to tie your application to Spring, then use @Autowire rather than the javax equivalent @Inject. I'd suggest that accepting a dependency to Spring is the best way to start.
On the difference between @Autowired
, @Inject
and @Resource
you can look here. Here you can thorough description and comparison.
What concerns the first difference: @Configuration
is used as replacement for XML
-based configuration, ie. it marks classes as the ones used for Java
-based configuration, see here. In turn, @Component
is actually used to mark classes as the ones to be instantiated by Spring
and @Configuration
is meta-annotated by @Component
annotation.
@Component
and @Configuration
serve different purposes so it doesn't make sense to compare them.
@Component
is equivalent to <bean>
,
@Configuration
is equivalent to <beans>
.
@Component
and @Configuration
are indeed very different types of annotations.
@Component
and similar annotations (@Service
, @Repository
, etc. )and its JSR-330 counterpart @Named
allow you to declare beans that are to be picked up by autoscanning with <context:component-scan/>
or @ComponentScan
they register the bean definition for the classes, so they are roughly equivalent to declaring the specified beans with the <bean ... />
tag in XML. This bean types will adhere to the standard proxy creation policies.
@Configuration
annotation was designed as the replacement of the XML configuration file. To create @Configuration
annotated beans, Spring will always use CGLIB
to subclass the @Configuration
annotated class, overriding its @Bean
annotated method to replace it with the bean lookup method to make singleton beans to be created only once. (Spring does not use CGLIB
to intercept internal method calls of normal Spring beans, it creates a separate instance of proxy instead(same way like JDK proxy does). Doing so allows to use proxies to avoid cardinality mismatch - for example a proxy singleton can fetch current session bean, which is not possible with class inheritance only. ). Despite that, @Configuration
annotated classes are still able to use annotated(@Autowired
, @Inject
etc.) fields and properties to request beans (and even other @Configuration
annotated beans too) from the container.
Example from 4.12.5 section of the documentation
@Configuration
public class AppConfig {
@Bean
public ClientService clientService1() {
ClientServiceImpl clientService = new ClientServiceImpl();
clientService.setClientDao(clientDao());
return clientService;
}
@Bean
public ClientService clientService2() {
ClientServiceImpl clientService = new ClientServiceImpl();
clientService.setClientDao(clientDao());
return clientService;
}
@Bean
public ClientDao clientDao() {
return new ClientDaoImpl();
}
}
in the example above only one ClientDao
instance will be created.
@Autowired
is Spring annotation, while @Inject
is a JSR-330 annotation.
@Inject
is equivalent to @Autowired
or @Autowired(required=true)
, but you can't get @Autowired(required=false)
behavior with the JSR-330 @Inject
annotation. This annotation always uses by-type autowiring.
Spring implements JSR-250 @Resource
annotation in a rather special way. @Resource
was originally designed for locating JNDI resources in Java EE, but Spring widens it applicability making it possible to wire to any bean in the container(JNDI resources are available as beans with the help of SimpleJndiBeanFactory).
The name of the corresponding bean can be specified as name
attribute of @Resource
annotation, if no name was specified, then the name of the annotated field or property will be used. Another strange feature is that if no bean with the property name was found spring will fallback to by-type wiring.
Example
Imagine that we have an AlphaClass
bean named beanAlpha and a BetaClass
bean beanBeta in the container.
@Resource
BetaClass something; // Wires to beanBeta - by-type
@Resource
BetaClass beanAlpha; // Will throw exception, because "beanAlpha" is not BetaClass -> it's a bad idea to use @Resource as a replacement of @Autowired
@Resource
Object beanAlpha; //Wires to beanAlpha - by-name
So it's a good practice to always specify resource name explicitly when using @Resource
annotation.
Documentation
Spring annotations
Bean standard annotations
update fixed JSR references as shevchik has pointed out. DI specific annotations are provided by JSR-330, which was developed by Google (Guice Framework) and SpringSource(Spring Framework) engineers. @Resource
is JNDI based and provided by JSR-250.