What is a bean in spring framework?
What is the use of the bean?
In the context of Spring, a bean is a managed object. What is a managed object? It's an object that Spring is aware of and that Spring knows how to manipulate, e.g. inject properties, invoke callback methods, etc.
There is then a difference between a regular java class (which Spring doesn't know about) and beans (which Spring knows about).
Generally Spring beans follow the Java bean convention, so that Spring can manipulate them easily. For instance if the bean is declared to have a property xxx, then Spring will expect getXxx and setXxx to be present. However, since Spring 2.X it is possible to dependency-inject private variables (using annotations), and therefore it is is no longer necessary to define a public setter in order to enable dependency injection for a property.
( The term bean is confusing in the sense that it is frequently uses to denote either (1) something that is managed by a container, like an enterprise java bean (EJB) or (2) something that adheres to the Java bean conventions. )
The Java Bean spec does spell out no-arg constructor, getters/setters, and serializable, but Spring does not require that your beans follow the spec. Spring deals with Plain Old Java Objects, whether they conform to the Java Bean spec or not.
What's the use of beans? They express your wishes in code. All Spring is doing is managing their lifecycle and wiring them together to accomplish your goals.
a bean is a POJO with setters and getters that follow the bean convention.
beans are used to pass around data, also jsps has special support for beans
A bean in Spring world is any object that is defined using Spring conventions using bean id or name. Its life time is managed by Spring container. The bean can be a POJO or a factory instance with static methods. It can even be a JNDI resource and not necessary a Java Bean. Bean managed by the Spring container can even be a proxy bean which may hide the bean (esp with TransactionProxyFactory).
In short, any bean whose lifetime is managed by Spring container is a Spring bean.
a bean is a class with a public standard constructor, getters/setters (properties) and it must be serializable. wikipedia has an explenation on this.
this way the spring framework knows how to create an instance of the bean (public standard constructor) and which properties exist (with reflection)
Related
I have a Spring boot project with many beans, so I can't just use my IDE to look understand the beans dependency tree.
So given a lazy bean method, how can I see why it was initialized? I mean what other Spring bean was dependent on it and resulted in its initialization?
Is creating objects by hand, i.e. using new operator instead of registering Spring bean and using dependency injection considered bad practice? I mean, does Spring IoC container have to know about all objects in the application? If so, why?
You want Spring to create beans for classes that :
you want/need to inject instance(s) in other beans
you need to inject beans (or dependencies) in their own instances.
you want them to benefit from Spring features (instantiation management, transaction management, proxy classes Spring empowered such as Repository/Interceptor and so for...)
Services, controllers or interceptors are example of them.
For example a controller may need inject a service or an interceptor.
As well as you don't want to handle the instantiation of these classes by implementing yourself the singleton pattern for each one. Which could be error-prone and require boiler plate code.
So you want all of these classes to be beans managed by Spring.
But you don't want to Spring create beans for classes that :
you don't want/need to inject instance(s) in other beans
you don't need to inject beans (or rdependencies) in their own instances
you don't need them benefit from Spring features
Entity, DTO, Value Object are example of them.
For example an entity never needs to be injected into another entity or in a service as a dependency because entities are not created at the container startup but are generally created inside a method and have a scope limited to the methods lifespan.
As well as you don't need Spring to create instances which the lifespan is a method. The new operator does very well the job.
So defining them as bean instances makes no sense and appears even counter intuitive.
Spring implements the Dependency Injection pattern. You should inject in the container of spring the beans that are going to be used in other classes as dependence to be able to work. Usually classes that implement interfaces are injected so that if you change the implementation, the classes that use that interface do not know about the change.
I recommend you read the post about the dependency injection of Martin Fowler.
Using new is not bad and you are just giving the IoC container the responsibility of using new under the hood. IoC will know about all the classes that you register with it. When using frameworks, it's even more important to think about the applications architecture, because a framework makes bad design as easy to implement as good design.
If you don't need multiple implementations of a class, then use new.
If you think it's plausible that you may need to switch between implementations, consider your app design and find a suitable injection point so that refactoring won't be such a drain.
If you need multiple implementation of a class, then use a design pattern like a factory or a DI framework.
Not every nook and cranny of an application needs to be highly configurable. That's what leads to over-engineered and hard to maintain code.
I am coming at this question from many years of using spring and just starting to look at JEE7 and CDI.
In the Spring world you have to stick #Component on a bean to turn into spring bean that spring will inject with dependencies but in CDI it seems that there is no equivalent of #Component.
To me CDI seems to imply that every class in my web application will be considered a CDI bean which seems undesirable because I have lot of java classes that are not using injection and I would not want some one to just stick #Inject in those classes and have CDI do its magic.
Two questions:
How to restrict what CDI considers to be a managed bean in a jar file?
What is the benefit for CDI to consider every bean to be a managed bean?
Please see the documentation for bean-discovery-mode in beans.xml. This attribute was only made available in JEE7 and is not available in JEE6.
EJB container serializes all business method invocations by default. And we have a couple of options to change it.
Apply the #Lock(LockType.READ)/#Lock(LockType.WRITE) annotations.
Or set #ConcurrencyManagement(ConcurrencyManagementType.BEAN) annotation on the bean class and use our custom synchronization policy (use syncrnozied blocks or don't use locks at all if bean only reads data, for example). The #Lock annotations is ignored in this case.
My question is how does Spring control it? How does it work be default?
Spring bean may be a stateless bean or may have a state. It can access some resource with read or write operations. And in different situations I need an option to control concurrency.
Could you please explain and compare this aspect of EJB/Spring containers.
EJB declarative concurency management applies only to singleton session beans, see javax.ejb.ConcurrencyManagement API. Regular session beans have no thread safety issues because containter insures that only one thread accesses a bean instance at any given time. As for Spring beans concurrency is not managed by container, programmers themselves should take care of it.
we recently converted our project from JBoss seam to using Spring and JSF. Our controller needs to initialize some properties. Right now were simply using the constructor to call the initialization methods. Seam has #Factory annotation decorated to a method which is called whenever the accessed property/field is null. Does Spring have an equivalent annotation? Thanks a lot.
No, but Spring supports the JSR-250 lifecycle annotations #PostConstruct / #PreDestroy, which you can use for housekeeping when your bean starts up.
In fact there are at least three mechanisms for bean lifecycle management, and their interaction and precedence is explained in the chapter "Combining lifecycle mechanisms"