Please enable JavaScript.

Coggle requires JavaScript to display documents.

Spring Framework (Security (Components (Request headers, Security filter…

- - - - Google
      - Okta
- - - - Application context
        
        Reads configuration metadata from
        
        Java annotations
        
        Java code
        
        XML file
        
        You should use an ApplicationContext unless you have a good reason for not doing so, with GenericApplicationContext and its subclass AnnotationConfigApplicationContext as the common implementations for custom bootstrapping. These are the primary entry points to Spring’s core container for all common purposes: loading of configuration files, triggering a classpath scan, programmatically registering bean definitions and annotated classes, and (as of 5.0) registering functional bean definitions.
      - For many extended container features, such as annotation processing and AOP proxying, the BeanPostProcessor extension point is essential. If you use only a plain DefaultListableBeanFactory, such post-processors do not get detected and activated by default. This situation could be confusing, because nothing is actually wrong with your bean configuration. Rather, in such a scenario, the container needs to be fully bootstrapped through additional setup.
    - - Instantiating the bean
        
        with instance factory method
        
        with a static factory method
        
        with a constructor
      - Wiring the beans together
      - Configuring the beans
      - Managing the bean's entire lifecycle
    - - Types
        
        Setter-based
        
        For optional dependencies
        
        Could use Required annotation to make property required dependency
        
        Constructor-based
        
        Could lead to circular dependencies
        
        For mandatory dependencies
        
        On fields
      - Special cases
        
        Lazy-initialized beans
        
        Works only if not a dependency of a singleton bean
        
        Defers instantiation of bean from IoC container to the moment when it's first requested
        
        Inject prototype bean B into singleton A on each method invocation of A
        
        Problem
        
        The container creates the singleton bean A only once, and thus only gets one opportunity to set the properties. The container cannot provide bean A with a new instance of bean B every time one is needed.
        
        Solution
        
        Make bean A aware of the container by implementing the ApplicationContextAware interface, and by making a getBean("B") call to the container ask for (a typically new) bean B instance every time bean A needs it.
        
        Not desirable as create coupling with Spring Framework
        
        Lookup method injection
        
        Ability of the container to override methods on managed beans and return another named bean
        
        Spring implements this method injection by using bytecode generation from the CGLIB library to dynamically generate a subclass that overrides the method.
        
        How to use
        
        Create concrete class with abstract/concrete method that returns needed dependency
        
        Use XML <lookup-method> or Lookup or Lookup("beanName")
        
        Use provider
        
        he JSR-330 variant of this is called Provider and is used with a Provider<MyTargetBean> declaration and a corresponding get() call for every retrieval attempt.
        
        ObjectProvider<MyTargetBean>, which delivers several additional access variants, including getIfAvailable and getIfUnique.
        
        inject ApplicationContext with Autowired
  - - - Singleton
        
        (Default) single object instance for each Spring IoC container.
      - Prototype
        
        single bean definition to any number of object instances.
      - available only if you use a web-aware ApplicationContext
        
        Application
        
        single bean definition to the lifecycle of a ServletContext
        
        Websocket
        
        single bean definition to the lifecycle of a WebSocket
        
        Request
        
        single bean definition to the lifecycle of a single HTTP request
        
        Session
        
        single bean definition to the lifecycle of an HTTP Session.
      - Custom scope
    - - CGLIB proxies
        
        intercept only public method calls
      - JDK interface-based proxies
        
        Classes must Implement at least one interface
        
        Must be injected using interface
  - - - Aware interfaces
      - Lifecycle callbacks
        
        Internally BeanPostProcessor implementations are used to process any callback interfaces
        
        InitializingBean.afterPropertiesSet()
        
        How to use, sorted in the order of calls if all implemented
        
        implement interface InitializingBean afterPropertiesSet()
        
        PostConstruct annotation
        
        This annotation is a convenient way of declaring a postProcessAfterInitialization method. Whether the PostConstruct method will execute before or after any other postProcessAfterInitialization depends on the order property
        
        custom configured init() method
        
        Java configuration: use the initMethod attribute of Bean.
        
        XML-based configuration: use the init-method attribute to specify the name of the method that has a void no-argument signature
        
        lets a bean perform initialization work after the container has set all necessary properties on the bean
        
        disposableBean.destroy()
        
        interface lets a bean get a callback when the container that contains it is destroyed
        
        How to use, sorted in the order of calls if all implemented
        
        PreDestroy annotation
        
        custom configured init() method
        
        Java configuration: destroyMethod attribute of Bean.
        
        XML-based configuration: destroy-method attribute on the <bean/>
        
        implement interface DisposableBean destroy()
        
        Lifecycle interface
    - - implementing BeanPostProcessor interface
        
        Created before any bean
        
        Interact with newly created beans
        
        Example: to create BPP to print class and name of every bean
        
        methods
        
        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).
        
        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).
        
        You can configure multiple BeanPostProcessor instances, and you can control the order in which these BeanPostProcessors execute by setting the order property by implementing Ordered interface.
        
        Typical usecase: wrap the original bean in a proxy instance, like Transactional annotation.
        BPP will handle the original instance of the bean, it may call any methods on the target, but it also gets to return the actual bean instance that should be bound in the application context, which means that it can actually return any object it wants.
        Typical scenario: BPP wraps the target in a proxy instance to perform AOP or transaction management.
      - BeanFactoryPostProcessor
        
        operates on the bean configuration metadata
        
        A bean implementing BeanFactoryPostProcessor is called when all bean definitions will have been loaded, but no beans will have been instantiated yet.
        
        After loading the bean definitions from all styles of configurations, BeanFactoryPostProcessor comes into the picture to modify the definition of some beans, and then the container instantiates the beans. Finally, BeanPostProcessor works on the beans, and it can modify and change the bean object. This is the initialization phase.
        
        Spring includes a number of predefined bean factory post-processors, such as PropertyOverrideConfigurer and PropertySourcesPlaceholderConfigurer. You can also use a custom BeanFactoryPostProcessor — for example, to register custom property editors.
      - FactoryBean
        
        Using a FactoryBean can be a good practice to encapsulate complex construction logic or make configuring highly configurable objects easier in Spring.
        
        Provides 3 methods
        
        Object getObject()
        
        Returns an instance of the object this factory creates. The instance can possibly be shared, depending on whether this factory returns singletons or prototypes.
        
        boolean isSingleton()
        
        Class getObjectType()
        
        Returns the object type returned by the getObject() method or null if the type is not known in advance.
      - The Autowired, Inject, Value, and Resource annotations are handled by Spring BeanPostProcessor implementations. This means that you cannot apply these annotations within your own BeanPostProcessor or BeanFactoryPostProcessor types (if any). These types must be 'wired up' explicitly by using XML or a Spring Bean method.
    - - Primary
      - Qualifier
      - Value
      - Component
        
        Service
        
        Repository
        
        Adds automatic translation of exceptions
        
        Controller
      - Configuration and ComponentScan
      - Bean
        
        annotate factory method
      - Conditional
        
        Annotation indicates specific org.springframework.context.annotation.Condition implementations that should be consulted before a Bean is registered. Implementations of the Condition interface provide a matches(…) method that returns true or false.
      - Profile
    - - If a bean that implements the ApplicationListener interface is deployed into the context, every time an ApplicationEvent gets published to the ApplicationContext, that bean is notified
      - Observer design pattern
      - Main classes
        
        ApplicationListener interface
        
        ApplicationEvent class
      - Built-in Events
        
        ContextStartedEvent
        
        ContextRefreshedEvent
        
        ContextStoppedEvent
        
        ContextClosedEvent
        
        RequestHandledEvent
        
        ServletRequestHandledEvent
      - How to create own events (in the commens)
        
        Create bean that extends Spring’s ApplicationEvent base class
        
        To publish a custom ApplicationEvent, call the publishEvent() method on an ApplicationEventPublisher. Typically, this is done by creating a class that implements ApplicationEventPublisherAware and registering it as a Spring bean.
        
        To receive the custom ApplicationEvent, you can create a class that implements ApplicationListener and register it as a Spring bean
        
        Asynchronous listener
        
        If you want a particular listener to process events asynchronously, you can reuse the regular Async support.
        
        Limitations
        
        2 more items...
        
        You can register as many event listeners as you wish, but note that, by default, event listeners receive events synchronously. This means that the publishEvent() method blocks until all listeners have finished processing the event. One advantage of this synchronous and single-threaded approach is that, when a listener receives an event, it operates inside the transaction context of the publisher if a transaction context is available. If another strategy for event publication becomes necessary, see the javadoc for Spring’s ApplicationEventMulticaster interface and SimpleApplicationEventMulticaster implementation for configuration options.
  - - - Post process bean definitions
        
        Instantiate beans
        
        Setters called
        
        Bean Post Processors
        
        Bean ready for the use :tada:
        
        After dependency injection each bean goes through a post-processing phase in which further configuration and initialization may occur.
        
        Each bean is eagerly instantiated by default (created in right order with its dependencies injected).
        
        Special BeanFactoryPostProcessor beans invoked, it can modify the definition of any bean
      - The Configuration classes are processed and/or Components are scanned for and/or XML files are parsed.
      - Bean definitions added to BeanFactory (each indexed under its id)