@SpringBootApplication // same as @Configuration @EnableAutoConfiguration @ComponentScan
public class Application {

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

}

@Configuration:

Allow to register extra beans in the context or import additional configuration classes.

This annotation 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.

There are two modes in @Configuration Full and Lite:

Full @Configuration:

If a class is annotated with @Configuration then it is considered as a full configuration class. With this, it provides additional features such as “proxying”, which allows for the inter-bean method calls within the same class to be intercepted to ensure that the singleton scope is respected, and the same instance is returned each time.

@Configuration classes support inter-bean references. This allows the @Bean method to reference another @Bean method in the same configuration class to indicate a dependency.

@Configuration
public class MediumConfig {

    @Bean
    public MediumA mediumA() {
        return new MediumA(mediumB());
    }

    @Bean
    public MediumB mediumB() {
        return new MediumB();
    }
}

In the example above, the mediumA bean method is called the mediumB bean method to get a reference to the mediumB bean. Because of the proxying in full @Configuration, the mediumB method will not create a new mediumB instance each time it’s called instead, it will return the same instance from the Spring context. Spring will create a CGlib proxy of the class, ensuring that bean methods adhere to the singleton pattern.

Lite @Configuration:

If a class has methods annotated with @Bean but the class is not annotated with @Configuration, then it is considered a lite configuration. In this case, the bean methods are processed, but the class does not get CGlib-enhanced proxying, which means calling one @Bean method from another @Bean method in the same class will not respect the singleton scope of the beans.

Importing Configuration:

@Configuration
@Import({MediumConfig.class, DatabaseConfig.class})
public class MainConfig {
    // ...
}

Here MainConfig includes, the beans defined in MediumConfig and DatabaseConfig, this can achieved through the @Import annotation as defined above.

Profile-specific Configuration:

@Profile annotation can be used at the class level along with @Configuration or method level along with @Bean, to indicate that they should be loaded only for the particular active profiles.

@Configuration
@Profile("dev") // to load all beans when the spring active profile is dev
public class DataSourceConfig {

// ...    

}

@Configuration
public class DataSourceConfig {

  @Bean
  @Profile("prod") // to load only when the spring active profile is prod
  public DataSourceMySql dataSource() {
      return new DataSourceMySql();
  }
}

@EnableAutoConfiguration:

It enables the auto-configuration of the spring application based on the dependencies present in the classpath.

When Spring Boot's main class is annotated with @EnableAutoConfiguration or @SpringBootApplication, we are instructing Spring Boot to automatically configure the application based on jars present in the classpath like data sources, JPA repositories, Spring MVC and more.

Internal Working:

Spring Boot auto-configuration attempts to intelligently configure beans as per the requirements. It does this by scanning the classpath for specific classes that, if present, trigger the auto-configuration of certain features.

To see the internal working of the auto-configuration of spring boot, run the application in debug mode this can be done by setting the debug=true in the applcation.properties file. The logs can be seen below.

Positive matches:
-----------------

   AopAutoConfiguration matched:
      - @ConditionalOnProperty (spring.aop.auto=true) matched (OnPropertyCondition)

   AopAutoConfiguration.AspectJAutoProxyingConfiguration matched:
      - @ConditionalOnClass found required class 'org.aspectj.weaver.Advice' (OnClassCondition)

   DataSourceAutoConfiguration.PooledDataSourceConfiguration matched:
      - AnyNestedCondition 1 matched 1 did not; NestedCondition on DataSourceAutoConfiguration.PooledDataSourceCondition.PooledDataSourceAvailable PooledDataSource found supported DataSource; NestedCondition on DataSourceAutoConfiguration.PooledDataSourceCondition.ExplicitType @ConditionalOnProperty (spring.datasource.type) did not find property 'type' (DataSourceAutoConfiguration.PooledDataSourceCondition)
      - @ConditionalOnMissingBean (types: javax.sql.DataSource,javax.sql.XADataSource; SearchStrategy: all) did not find any beans (OnBeanCondition)

   DataSourceAutoConfiguration.PooledDataSourceConfiguration#jdbcConnectionDetails matched:
      - @ConditionalOnMissingBean (types: org.springframework.boot.autoconfigure.jdbc.JdbcConnectionDetails; SearchStrategy: all) did not find any beans (OnBeanCondition)
  
   // some auto-configuration classes

Negative matches:
-----------------

   ActiveMQAutoConfiguration:
      Did not match:
         - @ConditionalOnClass did not find required class 'jakarta.jms.ConnectionFactory' (OnClassCondition)

   AopAutoConfiguration.AspectJAutoProxyingConfiguration.JdkDynamicAutoProxyConfiguration:
      Did not match:
         - @ConditionalOnProperty (spring.aop.proxy-target-class=false) did not find property 'proxy-target-class' (OnPropertyCondition)

  // Other logs

Positive matches: Under this, you can find all the matched auto-configuration classes as per the jars present in the classpath.

Based on the starter dependencies or by default it will add the jars to the classpath, and then spring boot is intelligent enough to scan and load the beans as required.

For example, consider DataSourceAutoConfiguration class. There is a @ConditionalOnClass({DataSource.class, EmbeddedDatabaseType.class})
if the DataSource, and EmbeddedDatabaseType classes are available in the classpath then only auto-configure the default DataSource.

@AutoConfiguration(
    before = {SqlInitializationAutoConfiguration.class}
)
@ConditionalOnClass({DataSource.class, EmbeddedDatabaseType.class})
@ConditionalOnMissingBean(
    type = {"io.r2dbc.spi.ConnectionFactory"}
)
@EnableConfigurationProperties({DataSourceProperties.class})
@Import({DataSourcePoolMetadataProvidersConfiguration.class, DataSourceCheckpointRestoreConfiguration.class})
public class DataSourceAutoConfiguration {
//....
}

Then how does it automatically connect to the DB ?
It does by @EnableConfigurationProperties({DataSourceProperties.class})
If we observe the DataSourceProperties class, it is reading properties using the prefix “spring.datasource” the driverClassName, url, username etc., defined in the application properties or yml file.

@ConfigurationProperties(
    prefix = "spring.datasource"
)
public class DataSourceProperties implements BeanClassLoaderAware, InitializingBean {
    private ClassLoader classLoader;
    private boolean generateUniqueName = true;
    private String name;
    private Class<? extends DataSource> type;
    private String driverClassName;
    private String url;
    private String username;
    private String password;
    private String jndiName;
    // ...
}

Like this, you can refer to other auto-configuration classes for understanding.

Negative Matches: Under this, you can find all classes that are marked as, not eligible for the auto-configuration. Like ActiveMQAutoConfiguration, as did not find the required class.

Customizing Auto-configuration:

• Excluding Specific Configurations:
  You can exclude certain auto-configuration classes that you don’t want to apply using the exclude attribute of @EnableAutoConfiguration:

@SpringBootApplication
@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})
public class Application {
 public static void main(String[] args) {
  SpringApplication.run(Application.class, args);
 }
}

Or by using the spring.autoconfigure.exclude property in your application.properties or application.yml.

spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

• Overriding Auto-configured Beans:
  You can define your configurations to override the defaults provided by auto-configuration. For example, if you declare your own DataSource bean, Spring Boot will override this with the default one.

@Configuration
public class DataSourceConfig {

  @Bean
  @Profile("!dev" & "!test") // to load bean other than dev and test active profile
  public DataSource dataSource() {
  //get the properties from properties.
  // password from the secrets vault
  // and create DataSource
  return DataSource();
  }

}

@ComponentScan:

This is used to specify the packages that the spring framework should scan for the components, services, repositories, and configurations. It enables the detection of components(@Component), repositories(@Repository), services(@Service), and controllers(@Controller) that are annotated as such so that they can be registered as beans in the Spring application context.

By default, Spring Boot scans all the classes that are under the main class where @SpringBootApplication is annotated. Which defaults to scanning the package of the main class and all its sub-packages.

If you want to override the default component scan settings of @SpringBootApplication, you can add @ComponentScan with your custom configuration to your main application class.

@SpringBootApplication
@ComponentScan(basePackages = "com.example.medium")
public class MainClass {
  //...
}

When you have components in packages that are not sub-packages of your main configuration class, need to explicitly configure @ComponentScan to include those packages.

@Configuration
@ComponentScan(basePackages = "com.project.medium")
public class SubConfiguration {
  //...
}

Attributes of @ComponentScan:

• basePackages and basePackageClasses:
  These attributes are used to specify the packages to scan explicitly. If you prefer type-safety over string literals, you can use basePackageClasses.

//Here in this case. Spring Boot will scan the packages of the classes provided.
@ComponentScan(basePackageClasses = { MediumService.class, MediumRepository.class })

// Spring Boot will scan the packages provided as String literals
@ComponentScan(basePackages = "com.example.medium")

• includeFilters and excludeFilters:
  These attributes are used to include or exclude specific components from being scanned.

//Includes only components that are annotated with @Service, as defined FilterType.ANNOTATION
//and excludes components that are annotated with @Configuration as defined FilterType.ANNOTATION
@ComponentScan(
    basePackages = "com.example.medium",
    includeFilters = @Filter(type = FilterType.ANNOTATION, classes = Service.class),
    excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
)

• lazyInit:
  This attribute is used whether or not the beans should be initialized lazily.

@ComponentScan(lazyInit = true)

Conclusion:

• @Configuration: This annotation is a key element in defining application context configuration in a Spring or Spring Boot application. It provides a declarative approach to define beans and dependencies and supports inter-bean references, profile-specific and conditional configuration.
• @EnableAutoConfiguration: This annotation is a powerful feature in Spring Boot that helps developers set up and run the application with minimal configuration. It works by conditionally configuring beans based on the application’s classpath and the context environment.
• @ComponentScan: This annotation controls the detection and registering of the beans in the Spring application context of the application components. It provides the attributes and capabilities allowing us to structure your application correctly and maintain control over your application context.

Understanding how to use @Configuration, @EnableAutoConfiguration, and @ComponentScan effectively is essential for designing well-structured and maintainable Spring applications.

In Spring Boot, Data Transfer Object(DTO) validation is commonly done using the Bean Validation API (JSR 380). When annotating DTO fields with validation constraints like (@NotNull, @Size etc. ), the groups and payload attributes provide additional control over the validation process.

Groups:

The groups attribute allows you to categorize constraints into validation groups. This is useful when you want different validation rules to apply in different conditions.

For example, we might require certain validation constraints that should be applied only when creating the new object, and other validation constraints should be applied only when updating the object.

Define the validation groups as interfaces.

public interface createMedium{
// can be empty interface
}

public interface updateMedium{
// can be empty interface
}

In the DTO class use the above validation groups.

public class MediumDTO {
    @NotNull(groups = createMedium.class)
    @Size(min = 5, max = 20, groups = createMedium.class)
    private String username;

    @NotNull(groups = updateMedium.class)
    private String password;
    
    //setters and getters
}

When validating the MediumDTO, we can specify which group should be validated.

public void validate() {
  MediumDTO mediumDto = new MediumDTO();
  // ... populate mediumDto fields ...
  mediumDto.setUserName("medium");
  mediumDto.setPassword("********");
  
  Validator validator = Validation.buildDefaultValidatorFactory().getValidator();
  Set<ConstraintViolation<MediumDTO>> violations = validator.validate(mediumDto, CreateMedium.class);
  //Here it ensures that only the constraints associated with the CreateMedium group are validated.
  //In this example it is @NotNull, @Size constraints on username field are validated.

  //If it has a violation then throw the error
  if (violations != null && !violations.isEmpty()) {
    String error = violations.stream()
                    .map(violation -> violation.getPropertyPath()+" "+violation.getMessage())
                    .collect(Collectors.toList()).toString();
    throw new ResponseStatusException(HttpStatus.BAD_REQUEST, error);
  }
}

Benefits of Using Groups

• Contextual Validation: Groups enable you to validate the same DTO differently based on the operation being performed (e.g., create vs. update).

• Performance: They can improve performance by avoiding unnecessary validations that are not relevant to the current context.

• Modularity: Groups help to keep the validation rules modular and organized by context.

• Flexibility: They provide flexibility to apply different validation rules without the need to create separate DTOs for each context.

Conclusion

The use of validation groups in Spring Boot is a powerful feature for managing complex validation logic. It allows you to annotate a single DTO with different validation rules and selectively apply those rules based on the operation being performed, leading to cleaner, more maintainable code.

Payload:

The payload attribute is used to provide additional metadata or context about the validation constraint that can be used when a constraint violation occurs.

Payloads are defined as classes that implement the javax.validation.Payload interface.

public interface SeverityLevel {
    //can be empty
    interface Info extends Payload {}
    interface Warn extends Payload {}
    interface Error extends Payload {}
}

In the DTO class use the above payload interfaces.

Different payloads are associated with different validation constraints. If any constraint is violated, the payload associated with that constraint will be included in the constraint violation information.

public class MediumDto {

    @NotBlank(message = "Username is required", payload = SeverityLevel.Error.class)
    private String username;

    @Email(message = "Email must be valid", payload = SeverityLevel.Warn.class)
    private String email;

    @Size(min = 8, message = "Password must be at least 8 characters", payload = SeverityLevel.Info.class)
    private String password;
}

When a constraint violation occurs, the payloads can be inspected to determine the severity or type of the violation. This can be useful when you want to handle violations differently based on their payload.

public void validate() {
  MediumDTO mediumDto = new MediumDTO();
  // ... populate mediumDto fields ...
  Validator validator = Validation.buildDefaultValidatorFactory().getValidator();
  Set<ConstraintViolation<MediumDTO>> violations = validator.validate(mediumDto);
 
  for (ConstraintViolation<UserDto> violation : violations) {
    Payload payload = violation.getConstraintDescriptor().getPayload().iterator().next();

    if (payload instanceof SeverityLevel.Error) {
        // Handle error-level violation
    } else if (payload instanceof SeverityLevel.Warn) {
        // Handle warning-level violation
    } else if (payload instanceof SeverityLevel.Info) {
        // Handle info-level violation
    }
}
}

Benefits of Using Payloads

• Metadata: Payloads provide a way to attach additional information or metadata to a constraint violation.

• Custom Handling: They allow for custom handling of constraint violations based on the payload information, such as logging different severity levels differently or presenting the user with different messages.

• Flexibility: Payloads offer flexibility in how you report and handle validation errors, making it possible to integrate with various error reporting or user notification systems.

Limitations and Considerations

While payloads provide useful context, they are not often used for carrying complex data because:

• They require casting from the Payload type to the specific payload interface.

• They are not intended for passing stateful information or complex data structures.

Conclusion

The payload attribute in DTO validation is a mechanism that allows developers to attach additional metadata to validation constraints. This can be particularly useful for differentiating the severity of constraint violations, customizing error handling with more meaningful messages, or integrating with other systems that might need to interpret the validation results differently based on the payload information. Although not required for simple validation cases, payloads can be an important tool in complex applications with advanced validation needs.

Besides predefined validators, when we need to validate a more particular type of input, we can create our custom validation logic.

This can be achieved by combining the custom annotation with a corresponding ConstraintValidator implementation.

Steps to create custom validation annotation:

• Create a custom annotation: Create an annotation and mark it with the @Constraint annotation, pointing to your ConstraintValidator implementation. Add any parameters you need in the custom annotation as annotation attributes.

@Documented
@Constraint(validatedBy = NumberValidator.class)
@Target({ ElementType.METHOD, ElementType.FIELD })
@Retention(RetentionPolicy.RUNTIME)
public @interface Number {

    int value() default 200; // The default length
 
    boolean isEmptyAllowed() default false; // Default to false

    String message() default "Number must be positive"; // Default error message

    Class<?>[] groups() default {}; // Required for validation constraints

    Class<? extends Payload>[] payload() default {}; // Required for validation constraints
}

• Implement the ConstraintValidator Interface: Create a class that implements the ConstraintValidator interface. This interface defines two methods: initialize (to initialize the validator) and isValid (to perform the validation logic).

public class NumberValidator implements ConstraintValidator<Number, String> {

    private static final Pattern CHECK = Pattern.compile("^[0-9]*$");

    private int number;

    private boolean isEmptyAllowed;

    @Override
    public void initialize(Number constraintAnnotation) {
        this.number = constraintAnnotation.value();
        this.isEmptyAllowed = constraintAnnotation.isEmptyAllowed();
    }

    @Override
    public boolean isValid(String value, ConstraintValidatorContext context) {
        if (StringUtils.isBlank(value)) {
          // ByDefault set to false in the custom annotation. 
          // or else get from the parameter defined in the annotation ex. @Number(length = 4, isEmptyAllowed = false; message = "Extension should not be greater than 4")
          // Got this value from the above initialize method (constraintAnnotation.isEmptyAllowed())
          return isEmptyAllowed;
        }
        // ByDefault set to 200 in the custom annotation.
        // or else get from the parameter defined in the annotation ex. @Number(length = 4, isEmptyAllowed = false; message = "Extension should not be greater than 4")
        // Got this value from the above initialize method (constraintAnnotation.value())
        // And check the given value matches the pattern.
        // If both condition satisfies return true
        return value.trim().length() <= length && CHECK.matcher(value).matches();
    }
}

• Use the Custom Annotation: After defining the custom annotation and its validator, use the annotation on fields.

public class PhoneExtensionDTO {

  // Here we are overriding the default properties of custom annotation 
  // of length, isEmptyAllowed, message
  @Number(length = 4, isEmptyAllowed = false; message = "Extension should not be greater than 4")
  private String extension;
}

When validating an instance of PhoneExtensionDTO, Spring’s validation mechanism will ensure that the extension field is not greater than 4 characters long, as specified by the @Number annotation.

To enable the validation, make sure that the @Valid annotation is used in the appropriate places, such as controller method parameters:

@RestController
public class MediumController {

    @PostMapping("/validate")
    public String validateExtension(@RequestBody @Valid PhoneExtensionDTO extension) {
        return "Validation passed!";
    }

}

The above code will result in validation being performed when a POST request is made to /validate, and if the extension does not meet the criteria, a validation error will be thrown.

Lifecycle Callbacks:

To interact with the container’s management of the bean lifecycle, you can implement the Spring “InitializingBean” and “DisposableBean” interfaces. The container calls afterPropertiesSet() and destroy() respectively perform certain actions upon initialization and destruction of your beans.

The JSR-250 “@PostContruct” and “@PreDestroy” annotations are generally considered best practices for receiving lifecycle callbacks in a modern Spring application. Using these annotations means that your beans are not coupled to Spring-specific interfaces. For details, https://medium.com/@saiteja-erwa/spring-boot-postconstruct-and-predestroy-69f364d9124a

Internally, the Spring Framework uses BeanPostProcessor implementations to process any callback interfaces it can find and call the appropriate methods. If you need custom features or other lifecycle behaviour Spring does not by default offer, you can implement a BeanPostProcessor yourself.

- Initialization Callbacks

The “org.springframework.beans.factory.InitializingBean” interface lets a bean perform initialization work after the container has set all necessary properties on the bean. The InitializingBean interface specifies a single method.

void afterPropertiesSet() throws Exception;

public class OrderBean implements InitializingBean {

 @Override
 public void afterPropertiesSet() {
  //Do some initialization work
 }
}

In the case of XML-based configuration metadata, you can use the “init-method” attribute to specify the name of the method that has a void no-argument signature.

<bean id="orderInitBean" class="examples.OrderBean" init-method="init"/>

public class SampleBean {

 public void init() {
  //Do some initialization work
 }
}

- Destruction Callbacks

Implementing the “org.springframework.beans.factory.DisposableBean” interface lets a bean get a callback when the container that contains it is destroyed. The DisposableBean interface specifies a single method.

void destroy() throws Exception;

public class OrderBean implements DisposableBean {

 @Override
 public void destroy() {
  // Do some destruction work (like releasing pooled connections)
 }
}

With XML-based configuration metadata, you can use the “destroy-method” attribute on the <bean/>

<bean id="orderDestructionBean" class="examples.OrderBean" destroy-method="cleanup"/>

public class OrderBean {

 public void cleanup() {
  // Do some destruction work (like releasing pooled connections)
 }
}

Combining Lifecycle Mechanisms

As of Spring 2.5, you have three options for controlling bean lifecycle behavior:

• The InitializingBean and DisposableBean callback interfaces
• Custom init() and destroy() methods
• The @PostContruct and @PreDestroy annotations

Multiple lifecycle mechanisms configured for the same bean, with different initialization methods, are called as follows:

1. Methods annotated with @PostContruct
2. afterPropertiesSet() as defined by the InitializingBean callback interface
3. A custom-configured init() method

Destroy methods are called in the same order:

1. Methods annotated with @PreDestroy
2. destroy() as defined by the DisposableBean callback interface
3. A custom-configured destroy() method

Startup and Shutdown Callbacks:

The Lifecycle interface defines the essential methods for any object that has its lifecycle requirements (such as starting and stopping some background process):

public interface Lifecycle {

 void start();// This method is called when the application context is started or refreshed. Beans that implement this method can perform any necessary tasks to start up, such as allocating resources or starting background threads

 void stop(); // This method is called when the application context is being closed, allowing beans to release any resources or perform other cleanup before the application is shut down.

 boolean isRunning(); // Which should return true if the component is currently running or false if it is not running
}

Any Spring-managed object may implement the Lifecycle interface. Then, when the ApplicationContext itself receives start and stop signals (for example, for a stop/restart scenario at runtime), it cascades those calls to all Lifecycle implementations defined within that context.

It does this by delegating to a LifecycleProcessor, as shown below:

public class LifecycleProcessor implements Lifecycle {

    private volatile boolean running = false;

    @Override
    public void start() {
        // Start the component.
        running = true;
        System.out.println("LifecycleBean has started.");
        // Perform startup logic here (e.g., start a background thread)
    }

    @Override
    public void stop() {
        // Stop the component.
        running = false;
        System.out.println("LifecycleBean has stopped.");
        // Perform shutdown logic here (e.g., stop a background thread)
    }

    @Override
    public boolean isRunning() {
        // Check if the component is currently running.
        return running;
    }
}

Once you define a bean that implements the Lifecycle interface, you can register it in the Spring application context (either through XML configuration, Java configuration, or component scanning), and the container will automatically call the start() and stop() methods at the appropriate times in the application’s lifecycle.

With Java configuration, you can use Java classes annotated with @Configuration to define your beans. Here’s an example of a Java config class that registers a Lifecycle bean:

@Configuration
public class AppConfig {

    @Bean
    public LifecycleProcessor myLifecycleBean() {
        return new LifecycleProcessor();
    }
}

Spring also provides a more specific SmartLifecycle interface, which extends the Lifecycle and adds more control over the startup and shutdown phases

Shutdown Callbacks:

This section applies only to non-web applications. Spring’s web-based ApplicationContext implementations already have code in place to gracefully shut down the Spring IoC container when the relevant web application is shut down.

ApplicationContextAware and BeanNameAware:

When an ApplicationContext creates an object instance that implements the org.springframework.context.ApplicationContextAware interface, the instance is provided with a reference to that ApplicationContext.

public interface ApplicationContextAware {

 void setApplicationContext(ApplicationContext applicationContext) throws BeansException;
}

The ApplicationContextAware interface is used when a bean needs access to the Spring ApplicationContext that it is defined in. For example, a bean might need to look up other beans, access resources, or query the environment settings.

@Component
public class AwareBean implements ApplicationContextAware {

    private ApplicationContext applicationContext;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) {
        this.applicationContext = applicationContext;
        // Use the application context as needed
    }

    // ...
}

The BeanNameAware interface is used by beans that want to know what their bean name is within the Spring container. This can be useful for beans that need to interact with the container more dynamically or when they need to relate their bean name to other operations within the application.

public interface BeanNameAware {

 void setBeanName(String name) throws BeansException;
}

@Component
public class MyBeanName implements BeanNameAware {

    private String beanName;

    @Override
    public void setBeanName(String name) {
        this.beanName = name;
        // You now know the bean's name within the container
    }

    // Other methods...
}

Invoked after the population of normal bean properties but before an init callback such as InitializingBean.afterPropertiesSet() or a custom init-method.

Notes:

• These interfaces are typically used by infrastructure beans or beans that provide framework-level functionality.
• It’s important to note that when using ApplicationContextAware it can lead to tightly coupling the code to Spring. As a best practice, consider using dependency injection if it is required instead of directly accessing the ApplicationContext.
• Beans that implement ApplicationContextAware and BeanNameAware must be Spring-managed beans to receive the callbacks correctly. They won’t work on POJOs that are not created by the Spring container.
• Other AwareInterfaces include MessageSourceAware, ResourceLoaderAware, and EnvironmentAware, each allowing access to various parts of the Spring framework’s functionality.

BeanPostProcessor:

Factory hook that allows for custom modification of new bean instances. For example, checking for marker interfaces or wrapping beans with proxies.

An ApplicationContext can autodetect BeanPostProcessor beans in its bean definitions and apply those post-processors to any beans subsequently created.

A plain BeanFactory allows for programmatic registration of post-processors, applying them to all beans created through the bean factory.

The BeanPostProcessor interface defines two callback methods that the Spring IoC container calls for each bean instance:

1. postProcessBeforeInitialization(Object bean, String beanName) : Apply this BeanPostProcessor to the given new bean instance before any bean initialization callbacks (like InitializingBean’s afterPropertiesSet() or a custom init-method).
2. postProcessAfterInitialization(Object bean, String beanName) : Apply this BeanPostProcessor to the given new bean instance after any bean initialization callbacks (like InitializingBean’s afterPropertiesSet or a custom init-method).

Example to implement custom BeanPostProcessor:

@Component
public class MediumBeanPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
        // This method can be used to perform some operations before the initialization
        // of the bean.
        System.out.println("Before initialization: " + beanName);
        return bean; // You can return any object, even a proxy around the bean.
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) {
        // This method can be used to perform operations after the initialization of the bean.
        // For instance, wrapping the bean with a proxy if necessary.
        System.out.println("After initialization: " + beanName);
        return bean; // You can return any object, even a proxy around the bean.
    }
}

Notes:

• It’s important to use this feature judiciously since it can impact the performance of your application if overused or used improperly.
• Since BeanPostProcessor itself is a bean, it follows the standard bean lifecycle and will go through its postProcessBeforeInitialization() and postProcessAfterInitialization() methods, so you need to be careful to avoid potential recursion issues if a BeanPostProcessor is processing itself.

The BeanFactory interface provides an advanced configuration mechanism capable of managing any type of object. The BeanFactory provides the configuration framework and basic functionality.

The ApplicationContext adds more enterprise-specific functionality. The ApplicationContext is a complete superset of the BeanFactory.

Users are sometimes unsure whether a BeanFactory or an ApplicationContext are best suited for use in a particular situation. Normally when building most applications in a J2EE environment, the best option is to use the ApplicationContext, since it offers all the features of the BeanFactory and adds on to it in terms of features, while also allowing a more declarative approach to the use of some functionality, which is generally desirable. The main usage scenario when you might prefer to use the BeanFactory is when memory usage is the greatest concern (such as in an applet where every last kilobyte counts), and you don’t need all the features of the ApplicationContext.

BeanFactory:

• The BeanFactory is the actual container that instantiates, configures, and manages several beans.
• The most commonly used simple BeanFactory implementation is org.springframework.beans.factory.xml.XmlBeanFactory
• The BeanFactory does have to be instantiated somehow. This can happen via explicit user code such as:

Resource res = new FileSystemResource("beans.xml");
XmlBeanFactory factory = new XmlBeanFactory(res);
or

Resource res = new ClassPathResource("beans.xml");
BeanFactory factory = new XmlBeanFactory(res);

• BeanFactory loads beans on demand. The beans defined in our BeanFactory will be loaded only when we explicitly call the getBean() method.

Resource res = new ClassPathResource("beans.xml");
BeanFactory factory = new XmlBeanFactory(res);
Medium medium = (Student) factory.getBean("medium");

ApplicationContext:

• While the beans package provides basic functionality for managing and manipulating beans, often programmatically, the context package adds ApplicationContext, which enhances BeanFactory functionality in a more framework-oriented style.

1. MessageSource, providing access to messages in, i18n-style.
2. Access to resources, such as URLs and files.
3. Event propagation to beans implementing the ApplicationListener interface.
4. Loading of multiple (hierarchical) contexts, allowing each to be focused on one particular layer, for example, the web layer of an application.

• There are so many implementation classes that can be used such as ClassPathXmlApplicationContext, FileSystemXmlApplicationContext, AnnotationConfigWebApplicationContext etc.

public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,
  MessageSource, ApplicationEventPublisher, ResourcePatternResolver {
  ....
}

Internationalization using MessageSource:

The ApplicationContext interface extends an interface called MessageSource and, therefore, provides internationalization (“i18n”) functionality. Spring provides three MessageSource implementations, ResourceBundleMessageSource, ReloadableResourceBundleMessageSource and StaticMessageSource.

1. Create the messages.properties file on the classpath:
2. Create a configuration class with bean definition.
3. Inject MessageSource in OrderService, and use the messageSource to read the message.

order.name=MobilePhone Order

@Configuration
public class OrderConfig {

  @Bean
  public MessageSource messageSource() {
    ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();
    messageSource.setBasename("config/messages");//{path}/{filename}
    return messageSource;
  }

}

@Service
public class OrderService {

  @Autowired
  public MessageSource messagSource;

  ....
  ..

  public getOrderMessage() {
    messageSource.getMessage("order.name", null, Locale.ENGLISH);
  }
}

When an ApplicationContext is loaded, it automatically searches for a MessageSource bean defined in the context. The bean must have the name messageSource. If such a bean is found, all calls to the preceding methods are delegated to the message source.

Event Handling:

Event handling in the ApplicationContext is provided through the ApplicationEvent class and ApplicationListener interface.

If a bean that implements the ApplicationListener interface is deployed into the context, every time an ApplicationEvent gets published to the ApplicationContext, that bean will be notified. Essentially, this is the standard Observer design pattern.

Spring provides three standard events:

ContextRefreshedEvent: Event published when the ApplicationContext is initialized or refreshed. Initialized here means that all beans are loaded, singletons are pre-instantiated and the ApplicationContext is ready for use.

@Component
public class AppEvents {

  @EventListener(ContextClosedEvent.class)
  public void onRefresh() {
    ////do something if all apps have initialised
  }
}

ContextClosedEvent: Event published when the ApplicationContext is closed, using the close() method on the ApplicationContext. Closed here means that singletons are destroyed.

@Component
public class AppEvents {

  @EventListener(ContextClosedEvent.class)
  public void onClosed() {
    ////do something if application Context closed
  }
}

RequestHandledEvent: A web-specific event telling all beans that an HTTP request has been serviced (i.e. this will be published after the request has been finished). Note that this event is only applicable for web applications using Spring’s DispatcherServlet.

@Component
public class AppEvents {

  @EventListener(RequestHandledEvent.class)
  public void onRequest() {
    ////do something on HTTP request.
  }
}

Example:

• Creating new application events by extending the ApplicationEvent class.
• Using ApplicationEventPublisher to notify all matching listeners registered of a specific application event.
• Registering the event listeners using the @EventListener annotation and implementing the ApplicationListener interface.
• If there are multiple listeners for a specific event then define the order using the @Order annotation.

Sometimes in an application, we may want to add the capability for listening to specific application events and processing these events for various audit purposes. Examples of these events can be when a new record is added or deleted, or a certain kind of transaction is completed or rolled back.

• Creating an Application Event
  An application event in Spring is represented by created by extending the ApplicationEvent class which is an abstract class.
  For example, if we want to notify the listeners whenever a new Order is placed then we can create a custom class OrderEvent as follows:

public class OrderEvent extends ApplicationEvent {

  public OrderEvent(Order order) {
    super(order);
  }

  @Override
  public String toString() {
    return "ApplicationEvent: New Order Placed :: " + this.getSource();
  }
}

• With later versions of Spring, extending the ApplicationEvent is not mandatory.

public class OrderEvent {

  private Order order;

  public OrderEvent(Order order) {
    this.order = order;
  }

  public Order getOrder() {
    return order;
  }

  @Override
  public String toString() {
    return "ApplicationEvent: New Order Placed :: " + this.order;
  }
}

• Publishing an Application Event
  The ApplicationEventPublisher interface encapsulates the whole event publication functionality. To access the ApplicationEventPublisher in a class, we may, optionally, implement the ApplicationEventPublisherAware interface in that class; else the Spring injects it automatically in the runtime.
• After we have access to ApplicationEventPublisher, we can use the applicationEventPublisher.publishEvent() method which accepts an ApplicationEvent type as a method argument.

@Service
public class OrderService implements ApplicationEventPublisherAware {

  ApplicationEventPublisher applicationEventPublisher;

  @Override
  public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) {
    this.applicationEventPublisher = applicationEventPublisher;
  }

  public OrderService(OrderRepository repository) {
    this.repository = repository;
  }

  public Order create(Order order) throws ApplicationException {
    Order newOrder = repository.save(Order);
    if (newOrder != null) {
      applicationEventPublisher.publishEvent(new OrderEvent(newOrder));   //Notify the listeners
      return newOrder;
    }
    throw new ApplicationException("Order could not be placed");
  }
}

• Receiving an Application Event
  We can listen to the application events in two ways i.e. using the ApplicationListener interface or using the @EventListener annotation.
  To listen to certain events, a bean must implement the ApplicationListener interface and handle the events in the onApplicationEvent() method. Spring will notify a listener of all events, so you must filter the events by yourself.
  If we use generics, Spring will deliver only messages that match the generic type parameter. In this example, we are using generics code to listen only to the DeleteOrderEvent.

@Component
public class DeleteOrderEventListener implements ApplicationListener<DeleteOrderEvent> {

  @Override
  public void onApplicationEvent(DeleteOrderEvent event) {
    log.info(event.toString());
  }
}

• Using @EventListener annotation.
  Since Spring 4.1, we can annotate a method with @EventListener and register the event listener of the type of method argument.

@Component
public class OrderEventsListener {

  @EventListener
  void handleOrderEvent(AddOrderEvent event) {
    log.info(event.toString());
  }

  @EventListener
  void handleDeleteOrderEvent(DeleteOrderEvent event) {
    log.info(event.toString());
  }
}
// or it can be written as below
@EventListener({OrderEvent.class, DeleteOrderEvent.class})
void handleOrderEvents(OrderEvent event) {
  log.info(event.toString());
}

Low-level resources and the application context:

An application context is a ResourceLoader, able to be used to load Resources. A Resource is essentially a java.net.URL on steroids (in fact, it just wraps and uses a URL where appropriate), which can be used to obtain low-level resources from almost any location in a transparent fashion, including from the classpath, a filesystem location, anywhere describable with a standard URL, and some other variations. If the resource location string is a simple path without any special prefixes, where those resources come from is specific and appropriate to the actual application context type.

BeanPostProcessor and BeanFactoryPostProcessor:

1. A bean implementing BeanPostProcessor operate on bean (or object) instances which means that when the Spring IoC container instantiates a bean instance then BeanPostProcessor interfaces do their work.
2. A bean implementing BeanFactoryPostProcessor is called when all bean definitions will have been loaded, but no beans will have been instantiated yet. This allows for overriding or adding properties even to eager-initializing beans. This will let you have access to all the beans that you have defined in XML or that are annotated (scanned via component scan).

Differences:

An interceptor is used to intercept and process a request before it reaches a controller and/or just before the response is sent back to the client. Interceptors can be used for various purposes, such as logging, authentication, authorization, performance monitoring, and other cross-cutting concerns.

HandlerInterceptor:

Interceptors in Spring Boot are defined by implementing the HandlerInterceptor interface. The HandlerInterceptor interface defines three methods that you can override:

1. preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) :

default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
   throws Exception {

  return true;
 }

This method is called before the actual handler (controller) method is executed. It can be used to perform operations before sending the request to the controller.

Dispatcher Servlet processes a handler in an execution chain, consisting of any number of interceptors, with the handler itself at the end. With this method, each interceptor can decide to abort the execution chain or continue based on the return value true/false.

true: It continues the execution chain.
false: It aborts the execution chain.

2. postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) :

default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
   @Nullable ModelAndView modelAndView) throws Exception {
 }

This method is called after the handler method is executed, but before the view is rendered.

DispatcherServlet processes a handler in an execution chain, consisting of any number of interceptors, with the handler itself at the end. With this method, each interceptor can post-process an execution, getting applied in inverse order of the execution chain.

3. afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) :

default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
   @Nullable Exception ex) throws Exception {
 }

This method is called after the view is rendered. It can be used to perform cleanup operations, such as releasing resources.

Note: Will only be called if this interceptor’s preHandle method has successfully completed and returned true!

Example of an interceptor in spring boot:

@Component
public class MediumInterceptor implements HandlerInterceptor {

  @Override
  public boolean preHandle(HttpServletRequest request, 
                           HttpServletResponse response,
                           Object handler) {
    //Invoked before sending the request to the controller
    System.out.println("preHandle method called");
    return true;
  } 

  @Override
  public void postHandle(HttpServletRequest request, 
                         HttpServletResponse response,
                         Object handler,
                         ModelAndView modelAndView){
    //Invoked after processing the request and before the view is rendered.
    System.out.println("postHandle method called");
  }

  @Override
  public void afterCompletion(HttpServletRequest request, 
                              HttpServletResponse response,
                              Object handler,
                              Exception ex) {
    //Invoked after view is rendered
    //Performs cleanup operation
    System.out.println("afterCompletion method called");
  }

}

To register an interceptor, the configuration class implements an interface — “WebMvcConfigurer” which allows us to customize spring MVC configuration specific to our own needs, overriding its default behaviour.

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        //This tells the InterceptorRegistry to register the provided class as the Interceptor
        registry.addInterceptor(new MediumInterceptor());
    }
}

With this configuration, MediumInterceptor will be applied to every request processed by the Spring MVC dispatcher.

We can also specify URL patterns to which the interceptor should apply or exclude certain patterns using the methods addPathPatterns and excludePathPatterns, respectively:

registry.addInterceptor(new MediumInterceptor()).addPathPatterns("/medium/api/**");

This would only apply MediumInterceptor to paths that start with medium/api/.

Interceptors offer a powerful way to implement cross-cutting logic in Spring Boot applications in a clean and decoupled manner.

@PostConstruct:

The @PostContruct annotation is used on a method that needs to be executed after a bean is fully initialised, i.e., after all the dependency injection is done.

• It is called only once in the entire bean life cycle after all the initializations.
• This annotation is typically used for setup tasks that need to be performed.

import jakarta.annotation.PostConstruct;

@Component
public class CommonConfiguration {

  @PostConstruct
  public class init() {
    // Initialization logic goes here
    // like setting some threshold values or setting some properties...
  }
}

• The method on which the PostConstruct annotation is applied may be public, protected, package private or private.
• The method must not be static except for the application client.

This is because the lifecycle of application clients is different from other Jakarta EE components, and the application client container ensures that the static method is called appropriately.

• The method should not be final.

@PreDestroy:

The @PreDestroy annotation is used on a method that is called just before a bean is removed from the Spring container and destroyed. This method is used for cleanup purposes, such as releasing resources that the bean might be holding (like closing file resources or database connections).

import jakarta.annotation.PreDestroy;

@Component
public class CacheConfiguration {

  @PreDestroy
  public class destroy() {
    // cleanup logic goes here
    // closing file resources or database connections, closing cache manager
    HazleCast.shutdownAll();
  }
}

• The method on which PreDestroy is applied may be public, protected, package private or private.
• The method must not be static.
• The method should not be final.

In addition to these annotations, Spring also provides interfaces such as “InitializingBean” and “DisposableBean” with “afterPropertiesSet” and “destroy” methods, respectively. You can use these interfaces as an alternative to @PostConstruct and @PreDestroy, although the annotation-based approach is typically preferred for its simplicity and clarity.

RequestInterceptors

Zero or more RequestInterceptors may be configured for purposes such as adding headers to all requests. No guarantees are given about the order in which interceptors are applied.

use-case:
Example: If service-A is consuming with service-B using feignClient
1. Create a request interceptor

public class AddHeaderInterceptor implements RequestIterceptor {

@Override
public class apply(RequestTemplate requestTemplate) {
  requestTemplate.Header("trackingId", "124314..");
}

2. Create a common feignConfig class where we configure a bean for this AddHeaderInterceptor.

public class FeignConfig {

  @Bean
  public AddHeaderInterceptor commonAddHeaderInterceptro() {
      return new AddHeaderInterceptor();
  }
  
}

3. In actual FeignClient use this FeignConfig.

@FeignClient(value="service-b", url="placeholder-url", configuration=FeignConfig.class)
public interface commonFiegnClient {
  //requests to service-b
}

Interceptor will be called for every request, and add data using the provided RequestTemplate.
likewise, we can use this FeignConfig for other service consumption.

git merge: pulls in the latest changes from the main into the feature branch creating a new “merge commit” in the process. That binds the histories of both branches. If we do this a lot, we end up with lots of merge commits, which can make the history a bit messy.

git rebase: changes the base of our feature branch to the latest commit on the main and then replays our changes from there. It gives us a linear commit history. The branch changes onto the tip of the main and then performs a fast-forward merge. This is like straightening, so it’s all in one line.

Summary:
“git merge” gives us a complete picture of the commit history and branch evolution.

pros:
1. Preserve commit history.

cons:
1. Make the history messy.

“git rebase” tidies up history by moving commits to the main branch tip.

pros:
1. Allows for a cleaner commit history.
2. Provides a linear commit timeline.

cons:
1. Reduced traceability.
2. Solving rebase conflicts is usually harder than solving merge conflicts.

The non-singleton prototype scope of bean deployment results in the creation of a new bean instance every time a request for that specific bean is made. That is, the bean is injected into another bean or you request it through a getBean() method call on the container. As a rule, you should use the prototype scope for all stateful beans and the singleton scope for stateless beans.

We can define the scope of a bean as a prototype using the scope=”prototype” attribute of the element or
using @Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE) annotation.

@Configuration
public class ApplcationConfig {

    @Bean
    @Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE)
    public MessageService messageService() {
        return new FBMessageService();
    }
}

Lifecycle:

Spring does not manage the complete lifecycle of a prototype bean. The container instantiates, configures, and otherwise assembles a prototype object and hands it to the client, with no further record of that prototype instance.

Although initialisation lifecycle callback methods are called on all objects regardless of scope, in the case of prototypes, configured destruction lifecycle callbacks are not called. For prototype bean @PreDestroy method is not invoked.

The reason behind this is simple: Spring manages the full lifecycle of Singleton beans but with Prototype beans, it hands over the bean after initialisation. The destruction or cleanup of prototype beans falls outside of Spring’s responsibility.

The client code must clean up prototype-scoped objects and release expensive resources that the prototype beans hold.

Use a custom bean-post-processor which holds a reference to beans that need to be cleaned up.

Implement the following interfaces:

1. ApplicationContextAware
   This interface provides a callback method which receives a ApplicationContext object. This object is used in the post-processor class to identify all prototype beans via its .isPrototype(String beanName) method.
2. DisposableBean
   This interface provides a destroy() callback method invoked by the Spring container. We will call the destroy() methods of all our prototype beans from within this method.
3. BeanPostProcessor
   Implementing this interface provides access to post-process callbacks from within which, we prepare an internal List<Object> of all prototype objects instantiated by the Spring container. We will later loop through this List<Object> to destroy each of our prototype beans.
4. Finally implement the DisposableBean interface in each of your prototype beans, providing the destroy() method required by this contract.

package com.cisco.cjp.credential.service.it.common;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

import java.util.LinkedList;
import java.util.List;

public class PrototypeBeanPostProcessor implements BeanPostProcessor, DisposableBean, ApplicationContextAware {

    private ApplicationContext context;
    List<Object> prototypeBeans = new LinkedList<Object>();

    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        if (context.isPrototype(beanName)) {
            synchronized (prototypeBeans) {
                prototypeBeans.add(bean);
            }
        }

        return bean;
    }

    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.context = applicationContext;
    }

    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }

    public void destroy() throws Exception {
        synchronized (prototypeBeans) {
            for (Object bean : prototypeBeans) {
                if (bean instanceof DisposableBean) {
                    DisposableBean disposable = (DisposableBean)bean;
                    try {
                        disposable.destroy();
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                }
            }
            prototypeBeans.clear();
        }
    }
}