On scanning my Spring Boot project using Sonarqube, I got the issue on:
#PersistenceContext
private EntityManager em;
The issue says:
Spring #Component, #Controller, #Service, and #Repository classes are singletons by default, meaning only one instance of the class is ever instantiated in the application. Typically such a class might have a few static members, such as a logger, but all non-static members should be managed by Spring. That is, they should have one of these annotations: #Resource, #Inject, #Autowired or #Value.
Having non-injected members in one of these classes could indicate an attempt to manage state. Because they are singletons, such an attempt is almost guaranteed to eventually expose data from User1's session to User2.
This rule raises an issue when a singleton #Controller, #Service, or #Repository has non-static members that are not annotated with one of:
org.springframework.beans.factory.annotation.Autowired
org.springframework.beans.factory.annotation.Value
javax.annotation.Inject
javax.annotation.Resource
So, is this actually an issue? or just a False Positives? Is it good idea to move all these queries to JpaRepository?
Related
I'm working in a company where JPA #transactional are used within #Component beans. I've always been told that #Transactional should be used inside #Service beans. Does someone could explain spring mechanisms differences between those and what are the best pratctices .. and why
There is no difference.
Also, #Service and #Component are the same. #Service is just a stereotype that developers often use to indicate that the Spring Bean is kind of a Service (maybe in a DDD meaning or not)
First of all, there is no difference.
From the spring javadoc
#Component
Indicates that an annotated class is a "component". Such classes are considered candidates for auto-detection when using annotation-based configuration and classpath scanning.
...
#Transactional
Indicates that an annotated class is a "Service", originally defined by Domain-Driven Design (Evans, 2003) as "an operation offered as an interface that stands alone in the model, with no encapsulated state."
May also indicate that a class is a "Business Service Facade" (in the Core J2EE patterns sense), or something similar. This annotation is a general-purpose stereotype and individual teams may narrow their semantics and use it as appropriate.
This annotation serves as a specialization of #Component, allowing for implementation classes to be autodetected through classpath scanning.
Frankly speaking, they behave in the same way.
By using #Transactional annotation on a public method or class it simply creates a proxy with transaction code for you.
IMO great explanation of #Transactional
Spring Stereotype Annotations
I recently started exploring Spring Boot. I see that there are 2 ways to define Beans in Spring Boot.
Define #Bean in the class annotated with #SprinBootApplication
Define #Bean in a class annotated with #Configuration
I am also confused about stereo-type annotation #Repository #Service #Controller etc.
Can someone please explain how dependency-injection works with these annotations?
Yes it is possible.
Either you use #Bean in any of your #Configuration or #SpringBootApplication class or mark the bean classes explicitly with annotations like #Service, #Component #Repository etc.
#Service or #Component
When you mark a class with #Service or #Compoenent and if spring's annotation scanning scope allows it to reach to the package, spring will register the instances of those classes as spring beans.
You can provide the packages to be included/excluded during scan with #ComponentScan
#Bean
#Beans are marked on factory methods which can create an instance of a particular class.
#Bean
public Account getAccount(){
return new DailyAccount();
}
Now in you application you can simply #Autowire Account and spring will internally call its factory method getAccount, which in turn returns an instance of DailyAccount.
There is a simple difference of using #Bean vs #Service or #Compoenent.
The first one makes your beans loosely coupled to each other.
In the #Bean, you have flexibility to change the account implementation without even changing any of the account classes.
Consider if your classes instantiation is a multi-step operation like read properties values etc then you can easily do it in your #Bean method.
#Bean also helps if you don't have source code access to the class you are trying to instantiate.
Spring Boot auto-configuration attempts to automatically configure your Spring application based on the jar dependencies that you have added.
You need to opt-in to auto-configuration by adding the #EnableAutoConfiguration or #SpringBootApplication annotations to one of your #Configuration classes.
You are free to use any of the standard Spring Framework techniques to define your beans and their injected dependencies. For simplicity, we often find that using #ComponentScan (to find your beans) and using #Autowired (to do constructor injection) works well.
One way is to define #Bean in the class annotated with
#SprinBootApplication
If you see #SprinBootApplication it is combination of many annotation, and one of them is #Configuration. So when you define #Bean in the Main class, it means it's inside #Configuration class.
According to Configuration docs :
Indicates that a class declares one or more #Bean methods and may be
processed by the Spring container to generate bean definitions and
service requests for those beans at runtime.
class annotated with #Configuration
When you define #Bean is a class annotated with #Configuration class, it means it is the part of spring configuration all the Beans define in it all available for Dependency-Injection.
I have also seen some code where neither of the 2 above approaches
have been used and yet dependency injection works fine. I have tried
to research a lot on this but could not find any concrete answer to
this. Is this possible?
I am assuming you are talking about Sterio-type annotation. Every sterio type annotation has #Component, according to docs :
Indicates that an annotated class is a "component". Such classes are
considered as candidates for auto-detection when using
annotation-based configuration and classpath scanning.
#EnableBinding turns class into #Configuration, and it's documented that:
#RefreshScope works (technically) on an #Configuration class, but it might lead to surprising behaviour: e.g. it does not mean that all the #Beans defined in that class are themselves #RefreshScope. Specifically, anything that depends on those beans cannot rely on them being updated when a refresh is initiated, unless it is itself in #RefreshScope (in which it will be rebuilt on a refresh and its dependencies re-injected, at which point they will be re-initialized from the refreshed #Configuration).
So just a practical question: is there a way still to update some Receiver class annotated with #EnableBinding? I guess it would not be handled by the framework, and should be implemented with a custom #EventListener
For our simplest examples, we use the #Configuration classes where #EnableBinding is declared as the business logic beans themselves, which is made possible by the fact that #EnableBinding is a #Configuration and therefore a #Component. Since you don't need #EnableBinding on the Receiver bean itself, for example, I would separate the logic into a bean annotated with #RefreshScope. #EnableBinding itself is not subject to refresh, although the channels would be unbound/rebound on start/stop.
I think both #Component and #Service can be used to detect bean automatically, anyone can show me the difference between those two annotations?
The basic difference between both annotations is that #Service is a specialization of #Component.
See also spring documentation for #Service:
Indicates that an annotated class is a "Service" (e.g. a business
service facade).
This annotation serves as a specialization of #Component, allowing for
implementation classes to be autodetected through classpath scanning.
A specialization of component is also a #Repository and a #Controller
Further information can be found e.g. here.
As of and up to Spring 3.1, there is no difference in the way that Spring handles them. The docs say this, but in a rather obscure way:
Spring 2.5 introduces further stereotype annotations: #Component, #Service, and #Controller. #Component is a generic stereotype for any Spring-managed component. #Repository, #Service, and #Controller are specializations of #Component for more specific use cases, for example, in the persistence, service, and presentation layers, respectively. Therefore, you can annotate your component classes with #Component, but by annotating them with #Repository, #Service, or #Controller instead, your classes are more properly suited for processing by tools or associating with aspects. For example, these stereotype annotations make ideal targets for pointcuts. It is also possible that #Repository, #Service, and #Controller may carry additional semantics in future releases of the Spring Framework. Thus, if you are choosing between using #Component or #Service for your service layer, #Service is clearly the better choice. Similarly, as stated above, #Repository is already supported as a marker for automatic exception translation in your persistence layer.
So for now, #Service will be treated by Spring exactly the same as #Component, but #Service can be considered a form of documentation.
I'm not really sure why #Service was included in Spring 2.5 at all, since it doesn't seem to have any really purpose.
check the source code
#Target({ElementType.TYPE})
#Retention(RetentionPolicy.RUNTIME)
#Documented
#Component
public #interface Service {
/**
* The value may indicate a suggestion for a logical component name,
* to be turned into a Spring bean in case of an autodetected component.
* #return the suggested component name, if any
*/
String value() default "";
}
Service annotation is in turn annotated with #Component . There's nothing much in difference .
here is the explanation to why we need such specialisation...
In Spring 2.0 and later, the #Repository annotation is a marker for any class that
fulfills the role or stereotype (also known as Data Access Object or DAO) of a repository. Among the uses of this marker is the automatic translation of exceptions.
Spring 2.5 introduces further stereotype annotations: #Component, #Service, and #Controller. #Component is a generic stereotype for any Spring-managed component. #Repository, #Service, and #Controller are specializations of #Component for more specific use cases, for example, in the persistence, service, and presentation layers, respectively.
Therefore, you can annotate your component classes with #Component, but by annotating them with #Repository, #Service, or #Controller instead, your classes are more properly suited for processing by tools or associating with aspects. For example, these stereotype annotations make ideal targets for pointcuts.
Thus, if you are choosing between using #Component or #Service for your service layer, #Service is clearly the better choice. Similarly, as stated above, #Repository is already supported as a marker for automatic exception translation in your persistence layer.
There are many annotations in the Spring framework like #Component, #Service, #Repository, #Service #Resource and #Autowired etc.
What is the most appropriate way of injecting my daos in services, and my service class in the Spring Controller.
With so many annotations it is getting confusing especially with #Autowired working for all situations.
#Service and #Repository are just "sub-annotations" for #Component to specify the bean a bit more (to separete Services from Repositories for more sophisticated stuff). From the point of injection this three are equal.
For injection, there are 3:
#Resource
#Inject
#Autowired
#Autowired is the most powerful annotation, but #Resource (JSR-250) and #Inject (JSR-330) are standardized. — Anyway if you not plan to reuse your application in a non-Spring environment, then I would not pay to many attention to this concern.
See Annotation based configuration in Spring, best Spring Annotation tutorial for me.
I prefer to avoid annotations, especially if they start getting confusing. Nothing wrong with good old getter and setters in this case. Just gotta wire the bean on your own, which isn't so difficult that annotations are necessary.