Spring Concepts

 Bean Scopes

• Singleton
• Prototype
• Request
• Session
• Application
• WebSocket

Reference : link

Injecting dependencies

1. Constructor based
2. Setter based
3. Field based
• This approach might look simpler and cleaner, but we don't recommend using it because it has a few drawbacks such as:
• This method uses reflection to inject the dependencies, which is costlier than constructor-based or setter-based injection.
• It's really easy to keep adding multiple dependencies using this approach. If we were using constructor injection, having multiple arguments would make us think that the class does more than one thing, which can violate the Single Responsibility Principle.

Reference : link

Injecting Prototype into Singleton

• Every request to get prototype object from singleton bean will return same instance of prototype
• In order to return different prototype bean there are different ways
• Injecting ApplicationContext
• Method Injection with @Lookup annotation
• javax.inject API  

Reference  : link

Using bean outside of Spring context 

• Implement ApplicationContextAware 
• Inject into static field
• Then call context.getBean method

public class ApplicationContextUtils implements ApplicationContextAware {

  private static ApplicationContext ctx;

 private static final String USER_SERVICE = "userServiceBean";

  @Override

  public void setApplicationContext(ApplicationContext appContext)

      throws BeansException {

    ctx = appContext;

  }

  public static ApplicationContext getApplicationContext() {

    return ctx;

  }

  public static UserService getUserService(){ 

return ctx.getBean(USER_SERVICE);

}

}

Reference : Stackoverflow

Reference  : link

BeanFactory vs ApplicationContext

• BeanFactory loads beans on demand (Lazy loading)
• ApplicationContext loads all beans at startup (Easger loading)
• BeanFactory only when memory consumption is critical
• ApplicationContext provides
• Annotation based dependency injection
• Event publication
• Messaging (i18n)
• Easy integration with Spring AOP feature

Reference : Baeldung

@ExceptionHandler and Global Handler

Reference : Baeldung

@Autowire

• Allows Spring to resolve and inject collaborating beans into our bean
• by declaring all the bean dependencies in a Spring configuration file, Spring container can autowire relationships between collaborating beans. This is called Spring bean autowiring
• Resolving bean conflicts using @Qualifier annotation
• @Qualifier helps to avoid ambiguity
• @SpringBootApplication -  is equivalent to using @Configuration, @EnableAutoConfiguration, and @ComponentScan. When we run Spring Boot application, it will automatically scan the components in the current package and its sub-packages. Thus it will register them in Spring's Application Context, and allow us to inject beans using @Autowired.
• We can use autowiring on properties, setters, and constructors
• @Autowired(required = false) - makes bean optional. Otherwise throws NoSuchBeanDefinitionException 

Reference :  link

Design Patterns in Spring

• Singleton - The singleton pattern is a mechanism that ensures only one instance of an object exists per application. This pattern can be useful when managing shared resources or providing cross-cutting services, such as logging. By default, Spring creates all beans as singletons.
• Factory Method pattern - The factory method pattern entails a factory class with an abstract method for creating the desired object. For example : BeanFactory, ApplicationContextFactory are factory patterns
• Proxy - Proxies are a handy tool in our digital world, and we use them very often outside of software (such as network proxies). In code, the proxy pattern is a technique that allows one object — the proxy — to control access to another object — the subject or service. For example : @Transactioin annotation is creating proxy object
• Template - In many frameworks, a significant portion of the code is boilerplate code. For example, when executing a query on a database, the same series of steps must be completed:  Establish a connection, Execute query, Perform cleanup, Close the connection - These steps are an ideal scenario for the template method pattern.
  The template method pattern is a technique that defines the steps required for some action, implementing the boilerplate steps, and leaving the customizable steps as abstract. 
  For example : JDBC template, JMS, JPA templates 

Reference : link

Spring Events

• The event class should extend ApplicationEvent if we're using versions before Spring Framework 4.2. As of the 4.2 version, the event classes no longer need to extend the ApplicationEvent class.
• The publisher should inject an ApplicationEventPublisher object.
• The listener should implement the ApplicationListener interface.
• We can write our Custom events
• Spring allows us to create and publish custom events that by default are synchronous. This has a few advantages, such as the listener being able to participate in the publisher’s transaction context.
• In some cases, publishing events synchronously isn't really what we're looking for — we may need async handling of our events.We can turn that on in the configuration by creating an ApplicationEventMulticaster bean with an executor. The event, the publisher and the listener implementations remain the same as before, but now the listener will asynchronously deal with the event in a separate thread.
• Existing framework events - ContextRefreshedEvent, ContextStartedEvent, RequestHandledEvent etc

Reference  - link

@Async

• annotating a method of a bean with @Async will make it execute in a separate thread. In other words, the caller will not wait for the completion of the called method.
• enabling asynchronous processing with Java configuration.by adding the @EnableAsync to a configuration class
• Additional options : 
• annotation – By default, @EnableAsync detects Spring's @Async annotation and the EJB 3.1 javax.ejb.Asynchronous. We can use this option to detect other, user-defined annotation types as well.
• mode indicates the type of advice that should be used — JDK proxy based or AspectJ weaving.
• proxyTargetClass indicates the type of proxy that should be used — CGLIB or JDK. This attribute has effect only if the mode is set to AdviceMode.PROXY.
• order sets the order in which AsyncAnnotationBeanPostProcessor should be applied. By default, it runs last so that it can take into account all existing proxies.
• @Async has two limitations
• It must be applied to public methods only
• Self-invocation — calling the async method from within the same class — won't work.
  The reasons are simple: The method needs to be public so that it can be proxied. And self-invocation doesn't work because it bypasses the proxy and calls the underlying method directly.
• Methods With Void Return Type
• Methods With Return Type - by wrapping the actual return in the Future
• By default, Spring uses a SimpleAsyncTaskExecutor to actually run these methods asynchronously. But we can override the defaults at two levels: the application level or the individual method level.
• Override the Executor at the Method Level
• Override the Executor at the Application Level
• Exception Handling -When a method return type is a Future, exception handling is easy. Future.get() method will throw the exception. But if the return type is void, exceptions will not be propagated to the calling thread. So, we need to add extra configurations to handle exceptions.
• create a custom async exception handler by implementing AsyncUncaughtExceptionHandler interface
• handleUncaughtException() method is invoked when there are any uncaught asynchronous exceptions
• override the getAsyncUncaughtExceptionHandler() method to return our custom asynchronous exception handler

Reference : link