I have a simple Result data holder object that gets returned from a method.
I'm confused on what the right way of using or creating this object using Spring boot.
Should this class be marked with #Component annotation?
Can I just create this object using 'new Result()' or should I autowire and use it?
If I use 'new Result()' then this instance will not be managed by Spring. Is that understanding correct? What are the advantages or disadvantages of managed vs non-managed beans.
Thanks,
Sudha
If I use 'new Result()' then this instance will not be managed by Spring. Is that understanding correct? What are the advantages or disadvantages of managed vs non-managed beans.
Well the greatest difference is the Inversion Of Control IoC (aka Dependency Injection DI). If Result is managed by spring, you can autowire other spring beans (like services, components, repositories and so on) Moreover you can autowire the Result bean in other spring beans. More details can be found here
Can I just create this object using 'new Result()' or should I autowire and use it?
Well it depends on your scenario. For example if you have a JSON response in a Spring controller, well in this case it's better to use a classic POJO and create it because it depends on your business logic.
On the other side id your bean is a kind of service who can be used in other points of your project because it offers some methods, well in this case I guess it's good to autowire it and make it as a spring bean
Should this class be marked with #Component annotation?
Well as I said earlier it depends on your scenario. In the case you described (result of a method) maybe it's better to use a classical POJO. But you didn't provide enough information
Related
I am developing Spring MVC app, i need to implement singleton pattern for some kind of utilities, ex: imageuploader and others.
My question is: in what way to implement singleton for this utilities, to initialize beans for these classes and inject where i need like Controllers, Services, DAO?, or to use static field implementation of singleton to keep instance of this class?
First, try to avoid singleton as it's considered to be a bad practice. Also their interactions with other instances are difficult to test and validate, compared to non-singleton instances.
If you absolutely need it, I'd suggest you use a Spring bean so you can exploit the autowiring mechanism and Spring's bean lifecycle.
See the Beans section of the Spring reference doc for more info.
Using a Spring bean as will allow you to easily inject a mock in unit tests. However, you will only be able to access it from other Spring beans (or objects created by Spring beans that pass in a reference to it).
Also see this discussion in this question: Difference between static class and singleton pattern?
Traditionally, you'd use PropertyPlaceholderConfigurer to inject config from properties files into a Spring web-app. This blog discusses a variety of newer ways to do this with Spring.
Can I know what is the difference between dependency injection and autowiring? Whether autowiring is different from dependency injection?
Which is the best way to autowiring(XML based or annotation based)?
Short answer: Dependency Injection is a design pattern, and #autowired is a mechanism for implementing it.
The DI idea is that, instead of your object creating an object it needs (say by using new to instantiate it), this needed object - a dependency - is handed to your object, typically using the constructor or a setter method. If you autowire, you're injecting a dependancy. In this case, Spring uses reflection to make this work, so you're not using the constructor or a setter method, but you're still injecting the dependency.
To answer question 2, its your choice. Personally, I find the XML configuration files cumbersome and use annotations whenever I can. You can accomplish whatever configuration you need to do either way.
I'm new to Spring and a little confused about how it works. I get that I can use the application context to instantiate beans and have them populated. However, is the idea that I should be able to just write Bean b = new Bean() and then have Spring to somehow automagically populate that Bean?
I'm experimenting with Spring in a web application, and as far as I can see I need to inject the ApplicationContext into, say, the servlets to be able to instantiate other beans (services, daos etc.) from there. It's a bit cumbersome, but probably works.
However, is Spring meant to be able to hook into any object instantiation which happens on classes defined as beans in applicationContext.xml?
Spring is an Inversion of Control container. A bean is an object whose life cycle is managed by Spring. If you want Spring to populate an object, it needs to go through Spring, ie. it needs to be bean.
is Spring meant to be able to hook into any object instantiation
which happens on classes defined as beans in applicationContext.xml?
Spring doesn't hook into anything. You configure your beans and the relationships between them with Spring and Spring handles creating the instances and linking them up.
For domain objects, Spring provides a solution via the #Configurable annotation: http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/htmlsingle/#aop-atconfigurable
It requires compile- or load-time-weaving and, thus, introduces some additional complexity but having the convenience of using the standard new Bean() syntax plus Spring's autowiring is worth it in my opinion.
Alternatively, you could define your domain objects as beans with prototype scope and use some factory to create them using the Spring ApplicationContext.getBean() method. With a scope of prototype a new instance will be returned every time and since you go through the ApplicationContext, Spring will do all the dependency injection magic as usual.
As for services and other beans with singleton scope, you would typically NOT retrieve them by first injecting the ApplicationContext and using it but instead you would inject them via either a constructor, setter or annotation-based strategy. The documentation covers that in detail: http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/htmlsingle/#beans-factory-collaborators
I'm a fresher, I'm recently started learning Spring.In spring dependency injection,we
can inject a bean in 2 ways,one is through constructor and the other one is through
setter method.My question is, for what situations constructor injection is better and
for what situations setter method injection is better. my focus only on where to use?
Give me an example if possible... waiting for your valuable reply..
There is a third way: Field injection.
You can directly apply the Annotation #Resource, #Inject or #Autowire at a (even private) field. This field even does not need to hava a getter or setter.
If you are building a Spring application, and there is no plan to use the classes in a not Spring application or a library, then the field injection is enough for 90% of the classes.
I prefer it, because it is less code.
Of course if you use a constructor for mandatory references then there is no way to forget one of them when creating a new instance. But (and this is my point of view, that differs from Alef Arendsen in his 3 year old Spring 2.0 blog entry "Setter injection versus constructor injection and the use of #Required") you have a spring bean and not a simple class. And this bean is created by spring, not directly by you. So if you use #Resource, #Inject or #Autowire for fields or setter spring checks them too and do not put the bean and the whole application in service if not all references can be satisfied.
I'd say go for constructor injection.
In some cases go for setter injection if dependency is optional.
If you forced to use setter injection and use Spring, the use #Required to ask Spring to enforce it.
Apply common sense in all cases :)
Is it possible to specify another bean to inject in case that the first intended bean to be injected fails?
Lets say we have Bean1, Bean2, and Bean3. Bean1 requires Bean2 but if Bean2 fails to be injected for some reason, then I want Bean3 to be injected instead. But each time Bean1 is retrieved from the container, it should always try to inject Bean2 first before attempting to inject Bean3. Is this possible? If not, what are my options?
Per me the question is flawed. In normal circumstances, Spring is supposed to be used for injecting the beans declaratively. So as pointed out by #Don Roby, #Adrian Shum the problem you are trying to solve is not for Spring.
Spring is not designed to resolve the dependency for you dynamically like a Service Locator.