Annotations - AyushiDamele/Spring GitHub Wiki

The following listing (from src/main/java/com/example/schedulingtasks/SchedulingTasksApplication.java) shows the application class:

package com.example.schedulingtasks;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.scheduling.annotation.EnableScheduling;

@SpringBootApplication
@EnableScheduling
public class SchedulingTasksApplication {

	public static void main(String[] args) {
		SpringApplication.run(SchedulingTasksApplication.class);
	}
}

Here: @SpringBootApplication is a convenience annotation that adds all of the following:

@Configuration: Tags the class as a source of bean definitions for the application context.

@EnableAutoConfiguration: Tells Spring Boot to start adding beans based on classpath settings, other beans, and various property settings. For example, if spring-webmvc is on the classpath, this annotation flags the application as a web application and activates key behaviors, such as setting up a DispatcherServlet.

@ComponentScan: Tells Spring to look for other components, configurations, and services in the com/example package, letting it find the controllers.

The @EnableSchedulingannotation is used to enable the scheduler for your application. This annotation should be added into the main Spring Boot application class file. It means that the application will be run again again in fixed amount of time.

The @ComponentScanannotation is used to automatically create beans for every class annotated with @Component,@Named, @Service, @Controller, @RestController, @Repository, ... and adds them to the Spring container (allowing them to be @Autowired)

@EntityScan: Set the packages scanned for JPA entities. Set the initial entity set used with Spring Data MongoDB, Neo4j, Cassandra and Couchbase mapping contexts.

@Component(From Spring 2.5 annotation-based dependency injection was introduced, which automatically scans and register classes as Spring bean which is annotated using @Component annotation. This means you don’t to declare that bean using the <bean> tag and inject the dependency, it will be done automatically by Spring.) is subdivided into multiple annotations:

  1. @Controller- @Component annotation does let’s see what does @Service, @Controller, and @Repository annotation do. They are nothing but the specialized form of @Component annotation for certain situations. Instead of using @Component on a controller class in Spring MVC, we use @Controller , which is more readable and appropriate.
  2. @Service- , @Service is used to annotated classes which hold business logic in the Service layer , for aceessing the database
  3. @Repository - this bean post processor adds an advisor to any bean that’s annotated with @Repository so that any platform-specific exceptions are caught and then rethrown as one of Spring’s unchecked data access exceptions.
  4. @Named- @Named works the same as @Component. However, the annotations @Controller, @Service, and @Repository are more specific. Many components, like Spring's DispatcherServlet (MVC configuration in WebApplicationContext) aren't looking for Component, they are looking for @Controller. So when it scans your class, it won't find it in @Named. In a similar fashion, transaction management with @Transactional looks for @Service and @Repository, not for the more generic @Component

@NoRepositoryBean- The annotation is used to avoid creating repository proxies for interfaces that actually match the criteria of a repo interface but are not intended to be one. It's only required once you start going into extending all repositories with functionality. Let me give you an example:

Assume you'd like to add a method foo() to all of your repositories. You would start by adding a repo interface like this

public interface com.foobar.MyBaseInterface<…,…> extends CrudRepository<…,…> {

  void foo();
}

You would also add the according implementation class, factory and so on. You concrete repository interfaces would now extend that intermediate interface:

public interface com.foobar.CustomerRepository extends MyBaseInterface<Customer, Long> {

}

Now assume you bootstrap - let's say Spring Data JPA - as follows:

<jpa:repositories base-package="com.foobar" /> You use com.foobar because you have CustomerRepository in the same package. The Spring Data infrastructure now has no way to tell that the MyBaseRepository is not a concrete repository interface but rather acts as intermediate repo to expose the additional method. So it would try to create a repository proxy instance for it and fail. You can now use @NoRepositoryBean to annotate this intermediate interface to essentially tell Spring Data: don't create a repository proxy bean for this interface.

That scenario is also the reason why CrudRepository and PagingAndSortingRepository carry this annotation as well. If the package scanning picked those up by accident (because you've accidentally configured it this way) the bootstrap would fail.

Long story short: use the annotation to prevent repository interfaces from being picked up as candidates to end up as repository bean instances eventually.

**@Audited **- Spring Data provides sophisticated support to transparently keep track of who created or changed an entity and the point in time this happened. To benefit from that functionality you have to equip your entity classes with auditing metadata that can be defined either using annotations or by implementing an interface.

⚠️ **GitHub.com Fallback** ⚠️