Spring notes

» https://docs.spring.io/spring/docs/5.0.3.RELEASE

//: # ()

Dependency injection is the process whereby a framework or such, for example the Spring framework, establishes the relationships between different parts of an application. This as opposed to the application code itself being responsible of establishing these relationships. When using the Spring framework for Java development, some of the advantages of dependency injection are:

• Reduced coupling between the parts of an application.
• Increased cohesion of the parts of an application.
• Increased testability.
• Better design of applications when using dependency injection.
• Increased reusability.
• Increased maintainability.
• Standardizes parts of application development.
• Reduces boilerplate code.

No code needs to be written to establish relationships in domain classes. Such code or configuration is separated into XML or Java configuration classes.

Spring Configuration

Interfaces recommended for Spring beans

The following are reasons why it is recommended to define interfaces that are later implemented by the classes implement the Spring beans in an application:

• Increased testability. Beans can be replaced with mock or stub objects that implement the same interface(s) as the real bean implementation.
• Allows for use of the JDK dynamic proxying mechanism.
• Allows for easier switching of Spring bean implementation.
• Allows for hiding implementation.

For instance, a service implemented in a module only have a public interface while the implementation is only visible within the module.

Hiding the implementation also allows the developer to freely refactor code to methods, without having to fear that such methods will be visible outside of the module containing the implementation.

XML Spring Configuration

In order to tell the Spring Container to create these objects and how to link them together, a configuration must be provided. 
This configuration can be provided using XML files or XML + annotations or Java Configuration classes.

Martin Fowler came up with the name Dependency Injection, to rename Inversion of Control principle

Constructor Injection

Constructor injection can be used to define beans when the bean type is a class that has a constructor with arguments defined.

<beans>
  <bean id="complexBean" class="com.ps.beans.ctr.ComplexBeanImpl">
        <constructor-arg ref=" simpleBean"/>
  </bean>
  
  <bean id= "simpleBean" class="com.ps.beans.SimpleBeanImpl"/>
</beans>

public class ComplexBeanImpl implements ComplexBean {
    private SimpleBean simpleBean;

    public ComplexBeanImpl(SimpleBean simpleBean) {
        this.simpleBean = simpleBean;
    }

}

• ref is used to tell the container that the value of this attribute is a reference to another bean.

<bean id="..." class="...">
        <constructor-arg ref="..."/>
</bean>

• value is used when the value to inject is a primitive types or their wrappers

<beans>
  <bean id="complexBean" class="com.ps.beans.ctr.ComplexBeanImpl">
        <constructor-arg ref="simpleBean"/>
        <constructor-arg value="true"/>
  </bean>
</beans>

public class ComplexBeanImpl {
      public ComplexBeanImpl(SimpleBean simpleBean, boolean complex) {
         this.simpleBean = simpleBean;
         this.complex = isComplex;
      }
}

• index attribute, which should be used when the constructor has more parameters of the same type.

<beans>
    <bean id="simpleBean0" class="com.ps.beans.SimpleBeanImpl"/>
    <bean id="simpleBean1" class="com.ps.beans.SimpleBeanImpl"/>
    
    <bean id="complexBean2" class="com.ps.beans.ctr.ComplexBean2Impl">
        <constructor-arg ref="simpleBean0" index="0"/>
        <constructor-arg ref="simpleBean1" index="1"/>
    </bean>
</beans>

public class ComplexBean2Impl {
    public ComplexBean2Impl(SimpleBean simpleBean1, SimpleBean simpleBean2) {
            this.simpleBean1 = simpleBean1;
            this.simpleBean2 = simpleBean2;
     }
 }

• Another way to handle constructors with more parameters of the same type is to use the name attribute

<beans>
    <bean id="simpleBean0" class="com.ps.beans.SimpleBeanImpl"/>
    <bean id="simpleBean1" class="com.ps.beans.SimpleBeanImpl"/>
    
    <bean id="complexBean2" class="com.ps.beans.ctr.ComplexBean2Impl">
        <constructor-arg ref="simpleBean0" name="simpleBean1"/>
        <constructor-arg ref="simpleBean1" name="simpleBean2"/>
    </bean>
</beans>

• c-namespace for reducing parameters injection via constructors

<beans>
    <bean id="simpleBean0" class="com.ps.beans.SimpleBeanImpl"/>
    <bean id="simpleBean1" class="com.ps.beans.SimpleBeanImpl"/>
    
    <!-- usage for reference to dependency -->
    <bean id="complexBean0" class="com.ps.beans.ctr.ComplexBeanImpl"
           c:simpleBean-ref="simpleBean0"/>
           
    <!-- usage for primitive type dependency -->
    <bean id="complexBean1" class="com.ps.beans.ctr.ComplexBeanImpl"
          c:simpleBean-ref="simpleBean0" c:complex="true"/>
          
    <!-- usage for index specified references -->
    <bean id="complexBean2" class="com.ps.beans.ctr.ComplexBean2Impl"
     c:_0-ref="simpleBean0" c:_1-ref="simpleBean1" />
     
</beans>

If you are using the name of the constructor parameter to inject the dependency, 
then the attribute definition with c: should match the pattern c:nameConstructorParameter[-ref], 
while if you are using indexes, the attribute definition should match c:_{index}[-ref].

Setter Injection

• When creating a bean using setter injection, the bean is first instantiated by calling the constructor and then initialized by injecting the dependencies using setters.
• <property /> element defines the property to be set and the value to be set with and does so using a pair of attributes: [name, ref] or [name,value].

<bean id="..." class="...">
        <property name="..." ref="..." />
</bean>

• The name is mandatory, because its value is the name of the bean property to be set.
• The ref is used to tell the container that the value of this attribute is a reference to another bean.
• The value, is used to tell the container that the value is not a bean, but a scalar value.

<beans>
    <bean id="simpleBean0" class="com.ps.beans.SimpleBeanImpl"/>
    <bean id="complexBean" class="com.ps.beans.set.ComplexBeanImpl">
         <property name="simpleBean" ref="simpleBean"/>
    </bean>
</beans>

public class ComplexBeanImpl implements ComplexBean {
    private SimpleBean simpleBean;
    
    public ComplexBeanImpl() {}
    
    public void setSimpleBean(SimpleBean simpleBean) {
        this.simpleBean = simpleBean;
    }
}

• p-namespace for reducing parameters injection via setters

<beans>
    <bean id="simpleBean" class="com.ps.beans.SimpleBeanImpl"/>
    <bean id="complexBean" class="com.ps.beans.set.ComplexBeanImpl"
           p:simpleBean-ref="simpleBean" p:complex="true"/>
</beans>

• Constructor and setter injection can be used together in creating the same bean

<beans>
    <bean id="simpleBean" class="com.ps.beans.SimpleBeanImpl"/>
    <bean id="complexBean2" class="com.ps.beans.set.ComplexBean2Impl">
        <constructor-arg ref="simpleBean"/>
        <property name="complex" value="true"/>
    </bean>
    
    <!-- configuration optimized using p-namespace and c-namespace -->
    <bean id="complexBean2" class="com.ps.beans.set.ComplexBean2Impl"
               c:simpleBean-ref="simpleBean" p:complex="true"/>
</beans>

//: # () | | | |

Collections

List

<bean id="simpleBean" class="com.ps.beans.SimpleBeanImpl"/>
<bean id="collectionHolder" class="com.ps.beans.others.CollectionHolder">
        <property name="simpleBeanList">
            <list>
                 <ref bean="simpleBean"/>
                 <bean class="com.ps.beans.SimpleBeanImpl"/>
                <null/>
            </list>
        </property>
</bean>

Set

<bean id="simpleBean" class="com.ps.beans.SimpleBeanImpl"/>
<bean id="collectionHolder" class="com.ps.beans.others.CollectionHolder">
        <property name="simpleBeanSet">
            <set>
                <ref bean="simpleBean"/>
            </set>
        </property>
</bean>

Map

<bean id="simpleBean" class="com.ps.beans.SimpleBeanImpl"/>
<bean id="collectionHolder" class="com.ps.beans.others.CollectionHolder">
      <property name="simpleBeanMap">
            <map>
                 <entry key="one" value-ref="simpleBean"/>
            </map>
        </property>
 </bean>

util namespace to deal with collections

• util namespace for reducing code working with collections

<beans>
    <bean id="simpleBean" class="com.ps.beans.SimpleBeanImpl"/>

    <util:list id=" simpleList" list-class="java.util.LinkedList">
        <ref bean="simpleBean"/>
        <bean class="com.ps.beans.SimpleBeanImpl"/>
        <null/>
    </util:list>
    
    <util:set id=" simpleSet" set-class="java.util.TreeSet">
        <ref bean="simpleBean"/>
    </util:set>
    
    <util:map id=" simpleMap" map-class="java.util.TreeMap">
        <entry key="one" value-ref="simpleBean"/>
    </util:map>

	<!--Injection collections-->
	<bean id="collectionHolder" class="com.ps.beans.others.CollectionHolder">
        <property name="simpleBeanList" ref="simpleList"/>
        <property name="simpleBeanSet" ref="simpleSet"/>
        <property name="simpleBeanMap" ref="simpleMap"/>
    </bean>
</beans>

Using Bean Factories

factory-method

• To use a singleton class to create a bean, the factory-method attribute is used, and its value will be the static method name that returns the bean instance

<beans>
    <bean id="simpleSingleton" class="com.ps.beans.others.SimpleSingleton"
          factory-method="getInstance" />
</beans>

public class SimpleSingleton {
    private static SimpleSingleton instance = new SimpleSingleton();
    private SimpleSingleton() { }
    
    public static SimpleSingleton getInstance(){
        return instance;
    }
}

factory-bean

• To use a factory object to create a bean, the factory-bean and factory-method attributes are used.

<beans>
    <bean id=" simpleBeanFactory" class="com.ps.beans.others.SimpleFactoryBean"/>
    <bean id="simpleFB" factory-bean="simpleBeanFactory" factory-method="getSimpleBean" />
</beans>

public class SimpleFactoryBean {
	
    public SimpleBean getSimpleBean() {
        return new SimpleBeanImpl();
    }
}

FactoryBean

By implementing this interface, the factory beans will be automatically picked up by the Spring container, and the desired bean will be created by automatically calling the getObject method

<beans>
    <bean id="smartBean" class=" com.ps.beans.others.SpringFactoryBean"/>
</beans>

public class SpringFactoryBean implements FactoryBean<SimpleBean> {
    
    private SimpleBean simpleBean = new SimpleBeanImpl();
    
    public SimpleBean getObject() {
        return this.simpleBean;
    }
	
    public Class<?> getObjectType() {
		return SimpleBean.class;
	}

	public boolean isSingleton() {
		return true;
	}
}    

FactoryBean

Bean Definition Inheritance

• Sometimes several beans need to be configured in the same way
• Use bean definition inheritance to define the common configuration once
  • Inherit it where needed

Import configuration files

<beans>
    <!-- using relative path, no prefix-->
    <import resource="ctr/sample-config-01.xml"/>
    <import resource="ctr/sample-config-02.xml"/>
    
    <!-- using classpath-->
    <import resource="classpath: spring/ctr/sample-config-01.xml"/>
    <import resource="classpath: spring/ctr/sample-config-02.xml"/>
    
    <!-- using classpath and wildcards-->
     <import resource="classpath: spring/others/sample-config-*.xml"/>
</beans>

Application Context

• In Spring, an object implementing the ApplicationContext interface is a container.
• The application context in a Spring application is a Java object that implements the ApplicationContext interface and is responsible for:
  • Instantiating beans in the application context.
  • Configuring the beans in the application context.
  • Assembling the beans in the application context.
  • Managing the life-cycle of Spring beans.

Some commonly used implementations of the ApplicationContext interface are:

• AnnotationConfigApplicationContext - Standalone application context used with configuration in the form of annotated classes.
  • This type of application context is used with standalone applications that uses Java configuration, that is classes annotated with @Configuration.
• AnnotationConfigWebApplicationContext - Same as AnnotationConfigApplicationContext but for web applications.
• ClassPathXmlApplicationContext - Standalone application context used with XML configuration located on the classpath of the application.
• FileSystemXmlApplicationContext - Standalone application context used with XML configuration located as one or more files in the file system.
• XmlWebApplicationContext - Web application context used with XML configuration.

The lifecycle of a Spring bean

The lifecycle of a Spring bean looks like this:

• Spring bean configuration is read and metadata in the form of a BeanDefinition object is created for each bean.
  • • For a configuration using Java Configuration annotations, the classpath is scanned by a bean of type org.springframework.context.annotation.ClassPathBeanDefinitionScanner, and the bean definitions are registered by a bean of type org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.
• All instances of BeanFactoryPostProcessor are invoked in sequence and are allowed an opportunity to alter the bean metadata.
• For each bean in the container:
  • An instance of the bean is created using the bean metadata.
  • Properties and dependencies of the bean are set.
  • BeanPostProcessor’s postProcessBeforeInitialization are given a chance to process the new bean instance before initialization.
  • Any methods in the bean implementation class annotated with @PostConstruct are invoked.
    • @PostConstruct is a standard Java lifecycle annotation, as specified in JSR-250.
    • An annotated method may have any visibility, may not take any parameters and may only have the void return type.
  • Any afterPropertiesSet method in a bean implementation class implementing the InitializingBean interface is invoked (this method is not recommended by the Spring).
    • While heavily used in the Spring framework, this method is not recommended by the Spring Reference Documentation since it introduce unnecessary coupling to the Spring framework.
  • Any custom bean initialization method is invoked. Bean initialization methods can be specified either in the value of the init-method attribute in the corresponding <bean> element in a Spring XML configuration or in the initMethod property of the @Bean annotation.
  • BeanPostProcessor’s postProcessAfterInitialization are given a chance to process the new bean instance after initialization.
  • The bean is ready for use.
• When the Spring application context is to shut down, the beans in it will receive destruction callbacks in this order:
  • Any methods in the bean implementation class annotated with @PreDestroy are invoked.
    • @PreDestroy is a standard Java lifecycle annotation, as specified in JSR-250.
    • An annotated method may have any visibility, may not take any parameters and may only have the void return type.
  • Any destroy method in a bean implementation class implementing the DisposableBean interface is invoked. If the same destruction method has already been invoked, it will not be invoked again. (this method is not recommended by the Spring)
    • While heavily used in the Spring framework, this method is not recommended by the Spring Reference Documentation since it introduce unnecessary coupling to the Spring framework.
  • Any custom bean destruction method is invoked. Bean destruction methods can be specified either in the value of the destroy-method attribute in the corresponding <bean> element in a Spring XML configuration or in the destroyMethod property of the @Bean annotation. If the same destruction method has already been invoked, it will not be invoked again.

• Initialization methods are always called when a Spring bean is created, regardless of the scope of the bean.
• With Spring beans that have prototype scope, that is for which a new bean instance will be created every time the Spring container receives a request for the bean, no destruction callback methods will be invoked by the Spring container.

BeanFactoryPostProcessor

• Configures bean definitions before beans are created.
  • Could change BeanDefinitions
• BeanFactoryPostProcessor may interact with and modify bean definitions, bean metadata, but it may not instantiate beans.
• BeanFactoryPostProcessor is an interface that defines the property (a single method) of a type of container extension point that is allowed to modify Spring bean meta-data prior to instantiation of the beans in a container. A bean factory post processor may not create instances of beans, only modify bean meta-data. A bean factory post processor is only applied to the meta-data of the beans in the same container in which it is defined in.
  • Example:
    • PropertySourcesPlaceholderConfigurer - allows for injection of values from the current Spring environment the property sources of this environment. ```java public class PropertySourcesPlaceholderConfigurer extends PlaceholderConfigurerSupport implements EnvironmentAware {

    } ```

    • DeprecatedBeanWarner - logs warnings about beans which implementation class is annotated with the @Deprecated annotation.
    • PropertySourcesPlaceholderConfigurer - is a BeanFactoryPostProcessor that resolves property placeholders, on the ${PROPERTY_NAME} format, in Spring bean properties and Spring bean properties annotated with the @Value annotation.
    • In XML activates by <context:property-placeholder location="classpath:db/db.properties" />
  • Example how to define own BPFP

public class DeprecationHandlerBeanFactoryPostProcessor implements BeanFactoryPostProcessor {

	@Override
	public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
		final String[] beanDefinitionNames = beanFactory.getBeanDefinitionNames();
		for (String name : beanDefinitionNames) {
			final BeanDefinition beanDefinition = beanFactory.getBeanDefinition(name);
			final String beanClassName = beanDefinition.getBeanClassName();
			try {
				final Class<?> beanClass = Class.forName(beanClassName);
				final DeprecatedClass annotation = beanClass.getAnnotation(DeprecatedClass.class);
				if (annotation != null) {
					beanDefinition.setBeanClassName(annotation.newImpl().getName());
				}
			}
			catch (Exception e) {
				e.printStackTrace();
			}
		}
	}
}

Static BeanFactoryPostProcessor

• BeanFactoryPostProcessor returning by @Bean methods this is a a special consideration must be taken for @Bean methods that return Spring BeanFactoryPostProcessor (BFPP) types. Because BFPP objects must be instantiated very early in the container lifecycle, they can interfere with processing of annotations such as @Autowired, @Value, and @PostConstruct within @Configuration classes. To avoid these lifecycle issues, mark BFPP-returning @Bean methods as static.
• Static @Bean methods can be defined in order to create, for instance, a BeanFactoryPostProcessor that need to be instantiated prior to the instantiation of any beans that the BeanFactoryPostProcessor is supposed to modify before the beans are being used.
• The ‘static’ modifier allows a method to be called without creating its containing configuration class as an instance.
• It is necessary when beans will get initialized early in the container lifecycle.
• It avoids triggering other parts of the configuration at that point of definition.
• They will never get intercepted by the container, not even within @Configuration classes.

@Bean
public static PropertySourcesPlaceholderConfigurer pspc() {
  // instantiate, configure and return pspc ...
}

BeanPostProcessor

• BeanPostProcessor is an interface that defines callback methods that allow for modification of bean instances.
• BeanPostProcessor tells spring there some processing that spring have to do after initialising a bean. Spring execute these method for each bean.
• BeanPostProcessor used to extend spring’s functionality.
• BeanPostProcessor may even replace a bean instance with, for instance, an AOP proxy.
  • Examples
    • AutowiredAnnotationBeanPostProcessor - implements support for dependency injection with the @Autowired annotation.
    • PersistenceExceptionTranslationPostProcessor - applies exception translation to Spring beans annotated with the @Repository annotation.
  • Example how to define own BPP

public class DisplayNameBeanPostProcessor implements BeanPostProcessor {

	@Override
	public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
		System.out.println("Called postProcessBeforeInitialization " + beanName);
		return bean;
	}

	@Override
	public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
		System.out.println("Called postProcessAfterInitialization " + beanName);
		return bean;
	}
}

• When defining a BeanPostProcessor using an @Bean annotated method, it is recommended that the method is static, in order for the post-processor to be instantiated early in the Spring context creation process.
  • The static modifier allows a method to be called without creating its containing configuration class as an instance.
  • It is necessary when beans will get initialized early in the container lifecycle.
  • It avoids triggering other parts of the configuration at that point of definition.
  • They will never get intercepted by the container, not even within @Configuration classes.

How BeanPostProcessor is different to a BeanFactoryPostProcessor?

• Both BeanPostProcessor and BeanFactoryPostProcessor are interfaces that allow for definition of container extensions.
• Both BeanPostProcessor and BeanFactoryPostProcessor instances operate only on beans and bean definitions respectively that are defined in the same Spring container.
• Classes implementing either the BeanPostProcessor or the BeanFactoryPostProcessor interfaces may also implement the Ordered interface in order to allow for setting a priority of a post-processor; a lower order value will cause the post-processor to be invoked earlier.
• When defining a BeanPostProcessor or a BeanFactoryPostProcessor using an @Bean annotated method, it is recommended that the method is static, in order for the post-processor to be instantiated early in the Spring context creation process.

Initializing beans priority

public class TriangleLifecycle implements InitializingBean {

	//  Calls #1
	@PostConstruct
	public void postConstruct(){
		System.out.println("TriangleLifecycle postConstruct : " + toString());
	}

	// Calls #2
	@Override
	public void afterPropertiesSet() throws Exception {
		System.out.println("TriangleLifecycle afterPropertiesSet : " + toString());
	}

	// Calls #3
	public void initMethod(){
		System.out.println("TriangleLifecycle initMethod : " + toString());
	}

}

@javax.annotation.PostConstruct

• The @PostConstruct annotation is part of the JSR-250 and is used on a method that needs to be executed after dependency injection is done to perform initialization
• The bean that registers @PostConstruct is org.springframework.context.annotation.CommonAnnotationBeanPostProcessor
  • When creating a Spring application context using an implementation that uses annotation-based configuration, for instance AnnotationConfigApplicationContext, a default CommonAnnotationBeanPostProcessor is automatically registered in the application context and no additional configuration is necessary to enable @PostConstruct and @PreDestroy.
• The methods that can be annotated with @PostConstruct must respect the rules:
  • they must have no arguments
  • return void
  • they can have any access right
• Transactions don’t configured/exists when @PostConstruct handled, that is why must not call data source in @PostConstruct method
  • Because @PostConstruct works before every proxy are configured
    • They configure in postProcessAfterInitialization stage in BPP, but @PostConstruct handles before postProcessAfterInitialization stage in BPP,

context namespace

• <context:annotation-config />
  • Enables scanning of all the classes in the project for annotations, so using it on large applications might make them slow
  • Activates various annotations to be detected in bean classes:
    • Spring’s @Required and @Autowired
    • JSR 250’s @PostConstruct, @PreDestroy and @Resource
  • JPA’s @PersistenceContext and @PersistenceUnit (if available).
  • Register post-processors:
    • AutowiredAnnotationBeanPostProcessor
    • CommonAnnotationBeanPostProcessor - is automatically registered in the application context and no additional configuration is necessary to enable @PostConstruct and @PreDestroy.
    • PersistenceAnnotationBeanPostProcessor
    • RequiredAnnotationBeanPostProcessor
• <context:component-scan />
  • Scans the classpath for annotated components that will be auto-registered as Spring beans.
  • By default, the Spring-provided @Component, @Repository, @Service, @Controller, @RestController, @ControllerAdvice, and @Configuration stereotypes will be detected.
  • Reduce the number of classes to be scanned
  • The use of <context:component-scan /> implicitly enables the functionality of <context:annotation-config />.
  • There is usually no need to include the <context:annotation-config /> element when using <context:component-scan />.

Context name space configuration example

Destroying beans priority

• These 2 ways will result in the publishing of a ContextClosedEvent. You can create a listener to listen to the mentioned event, and do some actions when the application context is closing. Both of them will result in doClose() being called. doClose() publishes the ContextClosedEvent.
  • Call close() on the application context
  • Use the registerShutdownHook() on the application context
• Called also when JVM exit normally
• Not called for prototype beans
• Destroying ways
  • Annotate a method with @PreDestroy, also part of JSR 250 and one of the first supported annotations in Spring.
  • Modify the bean to implement the org.springframework.beans.factory.DisposableBean interface and provide an implementation for the destroy() method (not recommended, since it couples the application code with Spring infrastructure).
  • Set a method to be called before destruction using the destroy-method attribute of the element.
    • The equivalent of destroy-method for Java Configuration @Bean(destroyMethod="...").

public class TriangleLifecycle implements DisposableBean {

	// Calls #1
	@PreDestroy
	public void preDestroy(){
		System.out.println("TriangleLifecycle preDestroy : " + toString());
	}

	// Calls #2
	@Override
	public void destroy() throws Exception {
		System.out.println("TriangleLifecycle destroy : " + toString());
	}

	// Calls #3
	public void destroyMethod(){
		System.out.println("TriangleLifecycle destroyMethod : " + toString());
	}
	
}

• Set the destroyMethod element of the @Bean annotation

@Bean(destroyMethod = "destroyMethod")
public MyBeanClass myBeanWithACloseMethodNotToBeInvokedAsLifecycleCallback() {
	final MyBeanClass theBean = new MyBeanClass();
	return theBean;
}

• Destroy method’s rules
  • The destroy method may be called only once during the bean lifecycle.
  • The destroy method can have any accessor; some developers even recommend to make it private, so that only Spring can call it via reflection.
  • The destroy method must not have any parameters.
  • The destroy method must return void.

Bean Scopes

• Default scope for a bean is singleton
  • One per IOC Container

<bean id="complexBean" class="com.ps.sample.ComplexBean" scope="prototype"/>

@Scope

• proxyMode
  • Define bean with scope request

    @Bean
    @Scope(value = WebApplicationContext.SCOPE_REQUEST, proxyMode = ScopedProxyMode.TARGET_CLASS)
    public HelloMessageGenerator requestScopedBean() {
        return new HelloMessageGenerator();
    }
      
  

  • Define controller in which autowire bean with scope request

    @Controller
    public class ScopesController {
          
        @Autowire
        private HelloMessageGenerator requestScopedBean;
       
        @RequestMapping("/scopes/request")
        public String getRequestScopeMessage(final Model model) {
            model.addAttribute("previousMessage", requestScopedBean.getMessage());
            requestScopedBean.setMessage("Good morning!");
            model.addAttribute("currentMessage", requestScopedBean.getMessage());
            return "scopesExample";
        }
    }
  

In case if we don’t specify scope for HelloMessageGenerator we will get error while instantiation ScopesController. proxyMode will fix this problem, this attribute is necessary because, at the moment of the instantiation of the web application context, there is no active request. Spring will create a proxy to be injected as a dependency, and instantiate the target bean when it is needed in a request.

public enum ScopedProxyMode {

	/**
	 * Default typically equals {@link #NO}, unless a different default
	 * has been configured at the component-scan instruction level.
	 */
	DEFAULT,

	/**
	 * Do not create a scoped proxy.
	 * <p>This proxy-mode is not typically useful when used with a
	 * non-singleton scoped instance, which should favor the use of the
	 * {@link #INTERFACES} or {@link #TARGET_CLASS} proxy-modes instead if it
	 * is to be used as a dependency.
	 */
	NO,

	/**
	 * Create a JDK dynamic proxy implementing <i>all</i> interfaces exposed by
	 * the class of the target object.
	 */
	INTERFACES,

	/**
	 * Create a class-based proxy (uses CGLIB).
	 */
	TARGET_CLASS;

}

Lazy and eager beans

• Singleton scoped beans in an application context are eagerly initialized by default, as the application context is created.
• Prototype scoped bean are typically created lazily when requested.
  • An exception is when a prototype scoped bean is a dependency of a singleton scoped bean, in which case the prototype scoped bean will be eagerly initialized.
• As a rule, use the prototype scope for all stateful beans and the singleton scope for stateless beans

Additional ways to create app context

- new AnnotationConfigApplicationContext(AppConfig.class);
- new ClassPathXmlApplicationContext(“com/example/app-config.xml”);
- new FileSystemXmlApplicationContext(“C:/Users/vojtech/app-config.xml”);
- new FileSystemXmlApplicationContext(“./app-config.xml”);

Depends-on

• Initialization of Bean monitoring will be after initialization of bean app

Accessing a Bean

Java Spring Configuration and Annotations

@Configuration

• Classes annotated with @Configuration contain bean definitions.
• Configuration classes cannot be final
  • The Spring container will create a subclass of each class annotated with @Configuration when creating an application context using CGLIB. Final classes cannot be subclassed, thus classes annotated with @Configuration cannot be declared as final.
  • Configuration classes are subclassed by the Spring container using CGLIB and final classes cannot be subclassed.
• @Bean methods can’t be final
• The reason for the Spring container subclassing @Configuration classes is to control bean creation for singleton beans, subsequent requests to the method creating the bean should return the same bean instance as created at the first invocation of the @Bean annotated method.
• Singleton beans are supported by the Spring container by subclassing classes annotated with @Configuration and overriding the @Bean annotated methods in the class. Invocations to the @Bean annotated methods are intercepted and, if a bean is a singleton bean and no instance of the singleton bean exists, the call is allowed to continue to the @Bean annotated method, in order to create an instance of the bean. If an instance of the singleton bean already exists, the existing instance is returned

Annotations

• Spring manages lifecycle of beans, each bean has its scope
• Default scope is singleton - one instance per application context
• Scope can be defined by @Scope(eg. @Scope(BeanDefinition.SCOPE_SINGLETON)) annotation on the class-level of bean class
• @Order is used to define sort order for components annotated with this annotation.
• Stereotypes annotations are used to mark classes according to their purpose:
  • @Component: Rootrstereotype, template for any Spring-managed component(bean).
  • @Repository: indicates that a class is a repository (persistence). template for a component used to provide data access, specialization of the @Component annotation for the the Dao layer.
  • @Service: template for a component that provides service execution, specialization of the @Component annotation for the Service layer.
  • @Controller: indicates that a class is a web controller. Template for a web component, specialization of the @Component annotation for the Web layer.
  • @RestController: indicates that a class is a specialized web controller for a REST service. Combines the @Controller and @ResponseBody annotations.
  • @Configuration: configuration class containing bean definitions (methods annotated with @Bean).
• @ComponentScan - To enable component scanning, annotate a configuration class in your Spring application with the @ComponentScan annotation. The default component scanning behavior is to detect classes annotated with @Component or an annotation that itself is annotated with @Component. Note that the @Configuration annotation is annotated with the @Component annotation and thus are Spring Java configuration classes also candidates for auto-detection using component scanning. Filtering configuration can be added to the @ComponentScan annotation as to include or exclude certain classes.

@ComponentScan(
    basePackages = "com.linnyk.learning",
    basePackageClasses = CalculatorService.class,
    excludeFilters = @ComponentScan.Filter(type = FilterType.REGEX, pattern = ".*Repository"),
    includeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = MyService.class)
)

@Configuration
@PropertySource("classpath:db/datasource.properties")
@ImportResource("classpath:spring/user-repo-config.xml")
@Import({DataSourceConfig.class,  UserRepoDSConfig.class})
@ComponentScan(basePackages = "com.ps")
public class DataSourceConfig {
    
    @Value("${driverClassName}")
    private String driverClassName;
    
    @Bean
    public static PropertySourcesPlaceholderConfigurer
           propertySourcesPlaceholderConfigurer() {
        return new PropertySourcesPlaceholderConfigurer();
    }
    @Bean
    public DataSource dataSource() throws SQLException {
        DriverManagerDataSource ds = new DriverManagerDataSource();
        ds.setDriverClassName(driverClassName);
        ds.setUrl(url);
        ds.setUsername(username);
        ds.setPassword(password);
        return ds;
    }
}

• @Bean
  • @Bean annotation is used to tell Spring that the result of the annotated method will be a bean that has to be managed by it.
  • @Bean annotation together with the method are treated as a bean definition, and the method name becomes the bean id.
  • @Bean ( initMethod = "init", destroyMethod = "destroy") - for declare init and destroy methods
  • Configure autowiring of dependencies; whether by name or type.
    • autowire() default Autowire.NO;
      • NO(AutowireCapableBeanFactory.AUTOWIRE_NO)
      • BY_NAME(AutowireCapableBeanFactory.AUTOWIRE_BY_NAME)
      • BY_TYPE(AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE)
  • The default bean name, also called bean id, is the name of the @Bean annotated method. This default id can be overridden using the name attribute of the @Bean annotation.
• @Lazy: dependency will be injected the first time it is used.
• @PropertySource annotation can be used to add a property source to the Spring environment.
  • The annotation is applied to classes annotated with @Configuration.

• @ImportResource for importing another configurations
• @Import annotation to import the bean definition in one class into the other.

• @ComponentScan works the same way as <context:component-scan /> for XML

• @ComponentScan - The default component scanning behavior is to detect classes annotated with @Component or an annotation that itself is annotated with @Component. Note that the @Configuration annotation is annotated with the @Component annotation and thus are Spring Java configuration classes also candidates for auto-detection using component scanning.

@ComponentScan(
	basePackages = "comlearnig",
	basePackageClasses = CalculatorService.class,
	excludeFilters = @ComponentScan.Filter(type = FilterType.REGEX, pattern = ".*Repository"),
	includeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = MyService.class)
)
public class SpringApplication {

}

Meta-Annotations

• Meta-annotations are annotations that can be applied to definitions of annotations. Note that this means that a meta-annotation must be applicable at type level, apart from any other locations it may appear at. The following example shows the definition of the Spring @RestController annotation:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Controller
@ResponseBody
public @interface RestController {
    
}

• This annotation is annotated with the Spring meta-annotations @Controller and @ResponseBody.

@Autowired

• Autowiring and initialization annotations are used to define which dependency is injected and what the bean looks like.
• Java Configuration and all other annotations: a org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor bean is used to autowire dependencies
• If a bean class contains one single constructor, then annotating it with @Autowired is not required in order for the Spring container to be able to autowire dependencies.
• If a bean class contains more than one constructor and autowiring is desired, at least one of the constructors need to be annotated with @Autowired in order to give the container a hint on which constructor to use.
• If there are multiple matching bean candidates and one of them is annotated with @Primary, then this bean is selected and injected into the field or parameter.
• If there are multiple matching bean candidates and the field or parameter is annotated with the @Qualifier annotation, then the Spring container will attempt to use the information from the @Qualifier annotation to select a bean to inject.
• If there is no other resolution mechanism, such as the @Primary or @Qualifier annotations, and there are multiple matching beans, the Spring container will try to resolve the appropriate bean by trying to match the bean name to the name of the field or parameter. This is the default bean resolution mechanism used when autowiring dependencies.
• If still no unique match for the field or parameter can be determined, an exception will be thrown.
• @Autowired: core annotation for this group; is used on dependencies to instruct Spring IoC to take care of injecting them.
  • Can be used on fields, constructors, setters and methods.
  • Use with @Qualifier from Spring to specify name of the bean to inject.
  • If a bean class contains one single constructor, then annotating it with @Autowired is not required in order for the Spring container to be able to autowire dependencies. If a bean class contains more than one constructor and autowiring is desired, at least one of the constructors need to be annotated with @Autowired in order to give the container a hint on which constructor to use.
  • Autowire by type then by name
  • Typed Map collections can be autowired as long as the expected key type is String.

     @Autowired
    public void setMovieCatalogs(Map<String, MovieCatalog> movieCatalogs) {
    this.movieCatalogs = movieCatalogs;
    }
    

  • When the Autowired annotation is used on an array field or an array method argument ‘MovieCatalog[]’, all beans of type MyClass in the Spring context, will be in the array injected.

    @Autowired
    private MovieCatalog[] movieCatalogs;
    

• @Inject: equivalent annotation to @Autowired from javax.inject package. Use with @Qualifier from javax.inject to specify name of the bean to inject.
• @Resource: equivalent annotation to @Autowired from javax.annotation package.
  • Autowire by name then by type
• @Required: Spring annotation that marks a dependency as mandatory, used on setters.

  @Required
  public void setMovieFinder(MovieFinder movieFinder) {
    this.movieFinder = movieFinder;
  }
  

• @Autowired may also be used for well-known “resolvable dependencies”, these interfaces will be automatically resolved, with no special setup necessary.
  • BeanFactory interface
  • ApplicationContext interface
  • Environment interface
  • ResourceLoader interface
  • ApplicationEventPublisher interface
  • MessageSource interface
• If the type that is autowired is a map with the key type being String, then the Spring container will collect all beans matching the value type of the map and insert these into the map with the bean name as key and inject the map.
• When autowiring arrays, collections or maps containing Spring beans, dependency injection will, as default, fail with an error if there are no matching beans.
  • Thus an empty array, collection or map will not be injected. If the array, collection or map parameter is made optional, null (and not an empty array, collection or map) will be injected if there are no beans of the matching type.

@Qualifier

• @Qualifier annotation can aid in selecting one single bean to be dependency-injected into a field or parameter annotated with @Autowired when there are multiple candidates.
• The most basic use of the @Qualifier annotation is to specify the name of the Spring bean to be selected the bean to be dependency-injected.
• The @Qualifier annotation can be used at three different locations:
  • At injection points.
  • At bean definitions.
  • At annotation definitions. This creates a custom qualifier annotation.

@Autowired
@Qualifier("userServiceImpl")
private UserService userService;

@Qualifier at Bean Definitions

• @Qualifier can also be applied on bean definitions by annotating a method annotated with @Bean in a configuration class with @Qualifier and supplying a value in the @Qualifier annotation.
• @Qualifier annotation can also be used on types and fields.
• @Qualifier annotation can be used on individual constructor arguments.
• @Qualifier annotations applied on collections (e.g. Set) are valid.
• The bean name is considered a default qualifier value.
• The @Qualifier annotation can be used at three different locations:
  • At injection points.
    • The most basic use of the @Qualifier annotation is to specify the name of the Spring bean to be selected the bean to be dependency-injected.
  • At bean definitions.
    • By annotating a method annotated with @Bean in a configuration class with @Qualifier and supplying a value in the @Qualifier annotation.
    • If a bean has not been assigned a qualifier, the default qualifier, being the name of the bean, will be assigned the bean.
  • At annotation definitions. This creates a custom qualifier annotation.

@Component
public class FactoryMethodComponent {

    @Bean
    @Qualifier("public")
    public TestBean publicInstance() {
        return new TestBean("publicInstance");
    }
    
    @Bean
    protected TestBean protectedInstance( @Qualifier("public") TestBean spouse) {
        //...
    }
}

@Bean

• @Bean annotation tells the Spring container that the method annotated with the @Bean annotation will instantiate, configure and initialize an object that is to be managed by the Spring container.
  • Configure autowiring of dependencies; whether by name or type.
  • Configure a method to be called during bean initialization - initMethod - this method will be called after all the properties have been set on the bean but before the bean is taken in use.
  • Configure a method to be called on the bean before it is discarded - destroyMethod
  • The default bean name is the name of the method annotated with the @Bean annotation and it will be used if there are no other name specified for the bean.
    • This functionality can be overridden, however, with the name attribute
  • To add a description to a @Bean the @Description annotation can be used
• Why @Bean method cannot be final?
  • Spring container subclass classes @Configuration classes and overrides the methods annotated with the @Bean annotation, in order to intercept requests for the beans. If the bean is a singleton bean, subsequent requests for the bean will not yield new instances, but the existing instance of the bean.
• The @Bean annotation can be used inside an @Configuration-annotated class.
• The @Bean annotation can be used inside an @Component-annotated class.

@Bean(name = "myFoo", initMethod = "init", destroyMethod = "cleanup")
@Description("Provides a basic example of a bean")
public Foo foo() {
	return new Foo();
}

Lookup method injection

• Lookup method injection is an advanced feature that you should use rarely. It is useful in cases where a singleton-scoped bean has a dependency on a prototype-scoped bean
• Configuration example

@Configuration
public class LMIConfiguration {

	@Bean
	@Qualifier("myCommand")
	@Scope("prototype")
	public Command command() {
		return new Command();
	}

	@Bean
	public CommandManager commandManager() {
		return new CommandManager() {
			
			@Override
			Command createCommand() {
				return command();
			}
		};
	}
}

• Beans example

public class Command {

	public void execute() {
		System.out.println("Command: " + this.hashCode());
	}

}

public abstract class CommandManager {

	@Lookup
	abstract Command createCommand();

	public void process() {
		System.out.println("CommandManager: " + this.hashCode());
		final Command command = createCommand();
		command.execute();
	}

}

• Application example. Prototype beans is different every time, but Singleton is unique

public class App {

	public static void main(String[] args) {
		ApplicationContext context = new AnnotationConfigApplicationContext(LMIConfiguration.class);
		final CommandManager commandManager = context.getBean(CommandManager.class);
		
		commandManager.process();
		// CommandManager: 81412691
		// Command: 717176949
		
		commandManager.process();
		// CommandManager: 81412691
		// Command: 1997353766
		
		commandManager.process();
		// CommandManager: 81412691
		// Command: 1288235781
	}
}

Bean Naming

• When the name is not defined for a bean declared with @Bean, the Spring IoC names the bean with the annotated method name.

// bean name = dataSource
@Bean
public DataSource dataSource() throws SQLException {

}

//bean name = one
@Bean(name="one")
public DataSource dataSource() throws SQLException {

}

//bean name =  one, alias = two
@Bean(name={"one", "two"})
public DataSource dataSource() throws SQLException {

}

• When the name is not defined for a bean declared with Component, the Spring IoC creates the name of the bean from the name of the bean type, by lowercasing the first letter.

// bean name = jdbcRequestRepo
@Repository
public class JdbcRequestRepo extends JdbcAbstractRepo<Request> implements RequestRepo{
       
}

// bean name = requestRepo
@Repository("requestRepo")
public class JdbcRequestRepo extends JdbcAbstractRepo<Request> implements RequestRepo{
         
}
// or
@Repository(value="requestRepo")
public class JdbcRequestRepo extends JdbcAbstractRepo<Request> implements RequestRepo{
         
}
//  or
// bean name = requestRepo
@Component("requestRepo")
public class JdbcRequestRepo extends JdbcAbstractRepo<Request> implements RequestRepo{
         
}

• @Description annotation, which was added in Spring 4.x is used to add a description to a bean

@Repository
@Description("This is not the bean you are looking for")
public class JdbcRequestRepo extends JdbcAbstractRepo<Request> implements RequestRepo {

}

Field Injection

• Dependency injection, regardless of whether on fields, constructors or methods, is performed by the AutowiredAnnotationBeanPostProcessor.
• @Autowire can be used on fields, constructors, setters, and even methods.
• In using @Autowired on constructors, it makes not sense to have more than one constructor annotated with it, and Spring will complain about it because it will not know what constructor to use to instantiate the bean.
• Out of the box, Spring will try to autowire by type
• If there are multiple matching bean candidates and one of them is annotated with @Primary, then this bean is selected and injected into the field or parameter.
• If there is no other resolution mechanism, such as the @Primary or @Qualifier annotations, and there are multiple matching beans, the Spring container will try to resolve the appropriate bean by trying to match the bean name to the name of the field or parameter. This is the default bean resolution mechanism used when autowiring dependencies.
• If still no unique match for the field or parameter can be determined, an exception will be thrown.
• If Spring cannot decide which bean to autowire based on type (because there are more beans of the same type in the application), it defaults to autowiring by name.
• @Qualifier - in case Spring finds more than candidate for autowiring to qualify which bean to inject
• @Autowired annotation by default requires the dependency to be mandatory, but this behavior can be changed, by setting the required attribute to true (@Autowired(required=false))
• If the type that is autowired is an array-type, then the Spring container will collect all beans matching the value-type of the array in an array and inject the array.
• If the type that is autowired is a map with the key type being String, then the Spring container will collect all beans matching the value type of the map and insert these into the map with the bean name as key and inject the map.

   @Qualifier("requestRepo")
   @Autowired
   RequestRepo reqRepo;

Constructor Injection

• Constructors in Spring bean classes can be annotated with the @Autowired annotation in order for the Spring container to look up Spring beans with the same types as the parameters of the constructor and supply these beans (as parameters) when creating an instance of the bean with the @Autowired - annotated constructor.
• If there is only one single constructor with parameters in a Spring bean class, then there is no need to annotate this constructor with @Autowired – the Spring container will perform dependence injection anyway.
• If there are multiple constructors in a Spring bean class and autowiring is desired, @Autowired may be applied to one of the constructors in the class.
  • Only one single constructor may be annotated with @Autowired.
• Constructors annotated with @Autowired does not have to be public in order for Spring to be able to create a bean instance of the class in question, but can have any visibility.
• If a constructor is annotated with @Autowired, then all the parameters of the constructor are required. Individual parameters of such constructors can be declared using the Java 8 Optional container object, annotated with the @Nullable annotation or annotated with @Autowired(required=false) to indicate that the parameter is not required. Such parameters will be set to null, or Optional.EMPTY if the parameter is of the type Optional.

@Repository("requestRepo")
public class JdbcRequestRepo  extends JdbcAbstractRepo<Request> implements RequestRepo{
	
    @Autowired
    public JdbcRequestRepo(DataSource dataSource) {
        super(dataSource);
    }
 }

Setter Injection

• Methods with any visibility.
  Example: Setter-methods annotated with @Autowired can be private – the Spring container will still detect and invoke them.
• If a method annotated with @Autowired, regardless of whether required is true or false, has parameters wrapped by the Java 8 Optional, then this method will always be invoked with the parameters for which dependencies can be resolved having a value wrapped in an Optional object. All parameters for which no dependencies can be resolved will have the value Optional.EMPTY.

public class JdbcUserRepo extends JdbcAbstractRepo<User> implements UserRepo {
	
	private DataSource dataSource;
    
	@Autowired
	public void setDataSource(DataSource dataSource) {
		this.dataSource = dataSource;
	}
    
    //or by name
     @Autowired
    public void setDataSource( @Qualifier("oracleDataSource") DataSource dataSource) {
        this.dataSource = dataSource;
    }
}

Method Injection

• Methods with more than one parameter.
• Methods with any visibility.
  Example: Setter-methods annotated with @Autowired can be private – the Spring container will still detect and invoke them.
• Methods that do not have a void return type.
• If a method annotated with @Autowired(required = false) has multiple parameters then this method will not be invoked by the Spring container, and thus no dependency injection will take place, unless all the dependencies can be resolved in the Spring context.
• If a method annotated with @Autowired, regardless of whether required is true or false, has parameters wrapped by the Java 8 Optional, then this method will always be invoked with the parameters for which dependencies can be resolved having a value wrapped in an Optional object. All parameters for which no dependencies can be resolved will have the value Optional.EMPTY.

@Configuration
public class MethodSecurityConfig {

  @Autowired
  public void registerGlobal(AuthenticationManagerBuilder auth) {
    // some business logic 
  }

}

Generic Injection

• This is useful when you have classes that are organized in a hierarchy and they all inherit a certain class that is generic, like the repositories in the project attached to the book, all of which extend JdbcAbstractRepo<T>

@ContextConfiguration(classes = {AllRepoConfig.class})
public class GenericQualifierTest {
	
    @Autowired
    JdbcAbstractRepo<Review> reviewRepo;
    
    @Autowired
    JdbcAbstractRepo<Response> responseRepo;

}

public class JdbcAbstractRepo<T extends AbstractEntity> implements AbstractRepo<T> {
	...
}

@Value annotation

• @Value - can be used to insert scalar values or can be used together with placeholders and SpEL in order to provide flexibility in configuring a bean
  • Such values can originate from environment variables, property files, Spring beans etc.
• Is used to inject value
  • system properties using ${} - these expressions are evaluated by the PropertySourcesPlaceholderConfigurer Spring bean prior to bean creation and can only be used in @Value annnotations.
  • SpEL using #{} - Spring Expression Language expressions parsed by a SpEL expression parser and evaluated by a SpEL expression instance.
• Can be on fields, constructor parameters or setter parameters
• On constructors and setters must be combined with @Autowired on method level, for fields @Value alone is enough
• Can specify default values
  • ${minAmount:100}"
  • ${personservice.retry-count:${services.default.retry-count}}
• @Value injection using SpEL
  • #{environment['minAmount'] ?: 100}
  • #{T(java.lang.Math).random() * 50.0 }
  • #{@systemProperties['os.name']}
  • path equivalent to PATH
  • java.home equivalent to JAVA_HOME
• The @Valuea annotation can be applied to:
  • Fields
    • Methods. Typically setter methods
  • Method parameters. Including constructor parameters. Note that when annotating a parameter in a method other than a constructor, automatic dependency injection will not occur. If automatic injection of the value is desired, the @Value annotation should be moved to the method instead.
    • Definition of annotations. In order to create a custom annotation.

	 @Value("${driverClassName}") private String driverClassName;
	 @Value("${url}") private String url;
	
	 @Value("#{dbProps.driverClassName}") String driverClassName,
	 @Value("#{dbProps.url}")String url,
	 @Value("#{dbProps.username}")String username,
	 @Value("#{dbProps.password}")String password

Spring Expression language (SpEL)

• Acronym SpEL
• can be used in @Value annotation values
• enclosed in #{}
• ${} is for properties, #{} is for SpEL
• Access property of bean #{beanName.property}
• Can reference systemProperties and systemEnvironment
• Used in other spring projects such as Security, Integration, Batch, WebFlow,…
• SpEL has support for:
  • Literal expressions.
    • Example string: ‘Hello World’
  • Properties, arrays, lists and maps.
    • Example create a list of integers: {1, 2, 3, 4, 5}
    • Example create a map: {1 : "one", 2 : "two", 3 : "three", 4 : "four"}
    • Example retrieve third item in list referenced by variable theList: #theList[3]
    • Example retrieve value from map in variable personsMap that has key “ivan”: #personsMap['ivan']
  • Method invocation.
    • Example invoke a method on a Java object stored in variable javaObject: #javaObject.firstAndLastName()
  • Operators.
    • Creating Java objects using new operator.
    • Ternary operator: ? :
    • The Elvis operator: ?:
    • Safe navigation operator: ?.
    • Regular expression “matches” operator: ‘168’ matches ‘\d+’
  • Variables
    • Variables are set on the evaluation context and accessed in SpEL expressions using the # prefix.
      • Example access the list in the numbersList variable: #numbersList
  • User defined functions
    • Implemented as static methods.
  • Referencing Spring beans in a bean factory (application context).
    • @mySuperComponent.injectedValue
  • Collection selection expressions.
    • Creates a new collection by selecting a subset of elements from a collection. Syntax: .?[]
  • Collection projection.
    • Creates a new collection by applying an expression to each element in a collection. Syntax: .![]
• The following entities can be referenced from Spring Expression Language (SpEL) expressions.
  • Static methods and static properties/fields.
    • T(com.linnyk.spring.MyBeanClass).myStaticMethod()
    • T(com.linnyk.spring.MyBeanClass).myClassVariable
  • Properties and methods in Spring beans. A Spring bean is references using its name prefixed with @ in SpEL.
    • Example accessing property on Spring bean: @mySuperComponent.injectedValue
    • Example invoking method on Spring bean: @mySuperComponent.toString()
  • Properties and methods in Java objects with references stored in SpEL variables. References and values stored in variables are referenced using the variable name prefixed with # in SpEL.
    • Example accessing property on Java object: #javaObject.firstName
    • Example invoking method on Java object: #javaObject.firstAndLastName()
  • (JVM) System properties. Available through the systemProperties reference, which is available by default.
    • Example retrieving OS name property: @systemProperties['os.name']
  • System environment properties.
    • Example KOTLIN_HOME environment variable: @systemEnvironment['KOTLIN_HOME']
  • Spring application environment. Available through the environment reference, also available by default.
    • Example retrieve name of first default profile: @environment['defaultProfiles'][0]
• Expressions starting with $. Such expressions reference a property name in the application’s environment. These expressions are evaluated by the PropertySourcesPlaceholderConfigurer Spring bean prior to bean creation and can only be used in @Value annnotations.
• Expressions starting with #. Spring Expression Language expressions parsed by a SpEL expression parser and evaluated by a SpEL expression instance.

Environment

• The Environment is a part of the application container. The Environment contains profiles and properties, two important parts of the application environment.

@Lazy

• This annotation can be used to postpone the creation of a bean until it is first accessed, by adding this annotation to the bean definition
• To explicitly set whether beans are to be lazily or eagerly initialized, the @Lazy annotation can be applied either to:

  • Methods annotated with the @Bean annotation.

    Bean will be lazy or not as specified by the boolean parameter to the @Lazy annotation (default value is true).

  • Classes annotated with the @Configuration annotation.

    All beans declared in the configuration class will be lazy or not as specified by the boolean parameter to the @Lazy annotation (default value is true).

  • Classes annotated with @Component or any related stereotype annotation.

    The bean created from the component class will be lazy or not as specified by the boolean parameter to the @Lazy annotation (default value is true).

@Component
@Lazy
public class SimpleBean { 
	
}

// or on a @Bean
@Configuration
public class RequestRepoConfig {
	
	@Lazy
	@Bean
	public RequestRepo anotherRepo(){
		return new JdbcRequestRepo();
}
}

// on injection point
@Repository
public class JdbcPetRepo extends JdbcAbstractRepo<Pet>
implements PetRepo {
    
    @Lazy
    @Autowired(required=false)
    public void setDataSource(DataSource dataSource) {
        this.dataSource = dataSource;
    }
}

@Profile

• Bean definition profiles is a mechanism that allows for registering different beans depending on different conditions.
  • Testing and development.
    Certain beans are only to be created when running tests. When developing, an in-memory database is to be used, but when deploying a regular database is to be used.
  • Performance monitoring.
  • Application customization for different markets, customers
• One or more beans can be configured to be registered when one or more profiles are active using the @Profile annotation.
• The beans in the below configuration class will be registered if the “dev” or “qa” profile is active.
• Beans with no profile is available in all profiles

@Profile({"dev", "qa"})
@Configuration
public class ConfigurationClass {
    
}

• Profile names in the @Profile annotation can be prefixed with !, indicating that the bean(s) are to be registered when the the profile with specified name is not active.
• Another example - @Profile("!a & !b"

@Profile("!prod")
@Configuration
public class ConfigurationClass {
    
}

• The @Profile annotation can be applied at the following locations:
  • At class level in @Configuration classes.
    • Beans in the configuration class and beans in configuration(s) imported with @Import annotation(s) will only be created and registered if the conditions in the @Profile annotation are met.
  • At class level in classes annotated with @Component or annotated with any other annotation that in turn is annotated with @Component.
    • The component will only be created and registered if the conditions in the @Profile annotation are met.
  • On methods annotated with the @Bean annotation.
    • Applied to a single method annotated with the @Bean annotations. The bean will only be created and registered if the conditions in the @Profile annotation are met.
  • Type level in custom annotations.
    • Acts as a meta-annotation when creating custom annotations.
• Activating Profile(s)
  • Programmatic registration of active profiles when the Spring application context is created.

      applicationContext.getEnvironment().setActiveProfiles("dev1", "dev2");
    

  • Using the spring.profiles.active property

     java -Dspring.profiles.active=dev1,dev2 -jar myApp.jar
    

  • In tests, the @ActiveProfiles annotation may be applied at class level to the test class specifying which the profile(s) that are to be activated when the tests in the class are run.
• There is a default profile named default that will be active if no other profile is activated.
• There does not seem to be any limitation concerning how many profiles that can be used in a Spring application. The Spring framework (in the class ActiveProfilesUtils) use an integer to iterate over an array of active profiles, which implies a maximum number of 2^32 – 1 profiles.

Close an application context

• Standalone Application
  • Registering a shutdown-hook by calling the method registerShutdownHook, also implemented in the AbstractApplicationContext class.
    This will cause the Spring application context to be closed when the Java virtual machine is shut down normally. This is the recommended way to close the application context in a non-web application.
  • Calling the close method from the AbstractApplicationContext class.
    This will cause the Spring application context to be closed immediately.
• Web Application
  • In a web application, closing of the Spring application context is taken care of by the ContextLoaderListener, which implements the ServletContextListener interface. The ContextLoaderListener will receive a ServletContextEvent when the web container stops the web application.
• Spring Boot Closing Application Context
  • Spring Boot will register a shutdown-hook as described above when a Spring application that uses Spring Boot is started. The mechanism described above with the ContextLoaderListener also applies to Spring Boot web applications.

Spring Test

• Unit Testing
  • Tests one unit of functionality
  • Keeps dependencies minimal
  • Isolated from the environment (including Spring)
• Integration Testing
  • Tests the interaction of multiple units working together – Integrates infrastructure
• TDD - This approach puts the design under question: if tests are difficult to write, the design should be reconsidered

• Trying to write at least two tests for each method: one positive and one negative, for methods that can be tested

• In order to define a test class for running in a Spring context, the following have to be done:
  • annotate the test class with @RunWith(SpringJUnit4ClassRunner.class)
  • annotate the class with @ContextConfiguration in order to tell the runner class where the bean definitions come from
  • use @Autowired to inject beans to be tested.
• Distributed as separate artifact - spring-test.jar
• Test class needs to be annotated with @RunWith(SpringJUnit4ClassRunner.class)
• Spring configuration classes to be loaded are specified in @ContextConfiguration annotation
  • @ContextConfiguration defines class-level metadata that is used to determine how to load and configure an ApplicationContext for integration tests. Specifically, @ContextConfiguration declares the application context resource locations or the annotated classes that will be used to load the context.
  • If no value is provided @ContextConfiguration, config file ${classname}-context.xml in the same package is imported
  • XML config files are loaded by providing string value to annotation - @ContextConfiguration("classpath:com/example/test-config.xml")
  • Java @Configuration files are loaded from classes attribute - @ContextConfiguration(classes={TestConfig.class, OtherConfig.class})
• To customize property values in a test, the @TestPropertySource annotation allows using either a test-specific property file or customizing individual property values.
• ReflectionTestUtils make it possible to access private properties:
  • Changing value of constants
  • Setting a value or reference into a non-public field.
  • Invoking a non-public setter method.
  • Invoking a non-public configuration or lifecycle callback method.
• Spring has mock objects on Environment, JNDI, and Servlet API to assist in unit testing.
• By default, the framework will create and roll back a transaction for each test.
• Tests that are annotated with @Transactional but have the propagation type set to NOT_SUPPORTED will not be run within a transaction.

Create an ApplicationContext in an integration test

Depending on whether JUnit 4 or JUnit 5 is used, the annotation @RunWith (JUnit 4) or @ExtendWith (JUnit 5) is used to annotate the test-class. In addition, the annotation @ContextConfiguration in both cases to specify either the XML configuration file(s) or the Java class(es) containing the Spring configuration to be loaded into the application context for the test.

JUnit 4 Example

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes={TestConfig.class, OtherConfig.class})
public final class FooTest  {
 
    @Autowired
    private MyService myService;
    
    @Test
    public void test() {
    	
    }
}

or

• AbstractJUnit4SpringContextTests implements ApplicationContextAware and therefore provide access to the ApplicationContext automatically.

@ContextConfiguration
public class MyTestClass extends AbstractJUnit4SpringContextTests {

}

JUnit 5 Example

@SpringJUnitConfig(classes={TestConfig.class, OtherConfig.class})
public final class FooTest  {
 
    @Autowired
    private MyService myService;
    
    @Test
    public void test() {
    	
    }
}

Testing Web Application Context

• Spring Unit test with @WebAppConfiguration
  • Creates a WebApplicationContext
  • Can test code that uses web features
    • ServletContext, Session and Request bean scopes
• Configures the location of resources
  • Defaults to src/main/webapp
  • For classpath resources use classpath: prefix

@SpringJUnitConfig(classes={TestConfig.class, OtherConfig.class})
@WebAppConfiguration
public final class FooTest  {
 
    @Autowired
    private MyService myService;
    
    @Autowired
    private WebApplicationContext mWebApplicationContext;
    
    @Test
    public void test() {
    	
    }
}

• The ApplicationContext is instantiated only once for all tests that use the same set of config files (even across test classes)
• Annotate test method with @DirtiesContext to force recreation of the cached ApplicationContext if method changes the contained beans

AnnotationConfigContextLoader

• @Configuration inner classes (must be static) are automatically detected and loaded in tests with help of AnnotationConfigContextLoader

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(loader = AnnotationConfigContextLoader.class)
public class SpringPetServiceTest3 {

     @Configuration
     public static class TestCtxConfig {
        @Bean
        StubPetRepo petRepo(){
            return new StubPetRepo();
        }
        @Bean
        PetService simplePetService(){
            SimplePetService petService = new SimplePetService();
            petService.setRepo(petRepo());
            return petService;
        }
    }
}

Testing with spring profiles

• @ActiveProfiles annotation of test class activates profiles listed
• @ActiveProfiles( { "foo", "bar" } )

Inject mocks using Mockito

• The @InjectMock has a behavior similar to the Spring IoC, because its role is to instantiate testing object instances and to try to inject fields annotated with @Mock or @Spy into private fields of the testing object.

public class MockPetServiceTest {
    
    @InjectMocks
    private SimplePetService simplePetService;
    
    @Mock
    private PetRepo petRepo;
    
    @Before
    public void initMocks() {
        MockitoAnnotations.initMocks(this);
    }
}

• With @RunWith(MockitoJUnitRunner.class) no need to MockitoAnnotations.initMocks(this)

@RunWith(MockitoJUnitRunner.class)
public class MockPetServiceTest {

    @InjectMocks
    private SimplePetService simplePetService;

    @Mock
    private PetRepo petRepo;

}

• PowerMock was born because sometimes code is not testable, perhaps because of bad design or because of some necessity. Below you can find a list of untestable elements:
  • static methods
  • classes with static initializers
  • final classes and final methods; sometimes there is need for an insurance that the code will not be misused or to make sure that an object is constructed correctly
  • private methods and fields

Testing Rest with Spring boot

• Can use SpringRunner as an alternative to the SpringJUnit4ClassRunner

@RunWith(SpringRunner.class)
@WebMvcTest(controllers = CustomerController.class, secure=false)
public class TestCustomerController {

	@MockBean
	private CustomerService service;

	@Autowired
	private MockMvc mockMvc;

	@Test
	public void testSuccessfulFindAllCustomers() throws Exception {
		when(service.findAllCustomers()).thenReturn(Arrays.asList(new Customer(), new Customer()));

		mockMvc.perform(get("/customers"))
            .andExpect(status().isOk())
            .andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8))
            .andExpect(jsonPath("$", hasSize(2)));
	}
	//..
}	

@RestController
@RequestMapping("/customers")
public class CustomerController {

	private CustomerService service;

	public CustomerController(CustomerService service) {
		this.service = service;
	}
	
	@GetMapping
	public ResponseEntity<Iterable<Customer>> findAllCustomers(){
		return ResponseEntity.ok(service.findAllCustomers());
	}
    //..
 }   
		

Testing JPA with Spring boot

@RunWith(SpringRunner.class)
@DataJpaTest
public class TestCustomerRepo {

	@Autowired
	private TestEntityManager entityManager;

	@Autowired
	private CustomerRepo repo;
	
	private Customer bojack;

	public TestCustomerRepo() {
		bojack = new Customer.CustomerBuilder().firstName("BoJack").middleName("Horse").lastName("Horseman")
				.suffix("Sr.").build();
	}

	@Test
	public void testFindAllCustomers() {
		this.entityManager.persist(bojack);
		Iterable<Customer> customers = repo.findAll();

		int count = 0;
		for (Customer repoCustomer : customers) {
			assertEquals("BoJack", repoCustomer.getFirstName());
			assertEquals("Horseman", repoCustomer.getLastName());
			assertEquals("Horse", repoCustomer.getMiddleName());
			assertEquals("Sr.", repoCustomer.getSuffix());
			assertTrue(repoCustomer.getId() > 0L);
			assertNull(repoCustomer.getDateOfLastStay());
			count++;
		}
		assertEquals(1, count);
	}
	//..
}	

Aspect Oriented Programming

AOP is a type of programming paradigm that aims to help with separation of cross-cutting concerns 
to increase modularity; it implies declaring an aspect class that will alter the behavior of 
base code, by applying advices to specific join points, specified by pointcuts.

• This is accomplished by specifying the following:
  • Location(s) in the code where code of the cross cutting concern is to be inserted.
  • Code of the cross cutting concern.
• Cross cutting concern
  • Cross cutting concern is functionality that is used in multiple locations throughout an application. Such functionality is applied/used in areas of an application that normally are not related to each other.
  • Cross cutting concerns do not usually fit well in the model of object-oriented or procedural programming.
• Examples of cross-cutting concerns:
  • Caching
  • Internationalization
  • Error detection and correction
  • Memory management
  • Performance monitoring
  • Synchronization
  • Logging
  • Transaction management
  • Security
  • Monitoring
  • Custom business rules
• Problems which AOP solve
  • Avoid code duplication.
  • Avoid mixing of, for instance, business logic and cross cutting concerns.
• The original library that provided components for creating aspects is named AspectJ.

AOP Terminology

• Aspect - An aspect brings together one or more pointcuts with one or more advice.
• Target object - object to which the aspect applies.
• Target method - the advised method.
• Advice - action taken by an aspect at a join point. In Spring AOP there are multiple advice types:
  • Before advice - methods annotated with @Before that will execute before the join point
  • After returning advice - methods annotated with @AfterReturning that will execute after a join point completes normally, meaning that the target method returns normally without throwing an exception.
  • After throwing advice - methods annotated with @AfterThrowing that will execute after a join point execution ends by throwing an exception.
  • After (finally) advice - methods annotated with @After that will execute after a join point execution, no matter how the execution ended.
  • Around advice - methods annotated with @Around intercept the target method and surround the join point. This is the most powerful type of advice, since it can perform custom behavior before and after the invocation
• Pointcut - a pointcut selects one or more join points out of the set of all join points in an application. Pointcut expressions can be defined as arguments for Advice annotations or as arguments for the @Pointcut annotation.
• Introduction - declaring additional methods, fields, interfaces being implemented, annotations on behalf of another type. Spring AOP allows you to introduce new interfaces (and a corresponding implementation) to any advised object.
• AOP proxy - the object created by AOP to implement the aspect contracts.
• Weaving - linking aspects with other application types or objects to create an advised object. This can be done at compile time (using the AspectJ compiler, for example), load time, or at runtime. Spring AOP, like other pure Java AOP frameworks, performs weaving at runtime.
  • Compile time weaving
    Byte code of classes is modified at compilation time at selected join points to execute advice code. The AspectJ compiler uses compile time weaving.
  • Load time weaving
    Byte code of classes is modified at class loading time when the application is run.
  • Runtime weaving
    Proxy objects are created at runtime when the application is run. The proxy objects are used instead of the original objects and divert method invocations to advice code. Spring AOP uses runtime weaving exclusively

@Aspect
@Component
public class LoggingAspect {
	
	/**
	* Pointcut that selects join points being method executions in the se package
	* and sub-packages in classes which name ends with "Service" having arbitrary
	* number of parameters.
	*/
	@Pointcut("execution(* se..*.*Service.*(..))")
	public void applicationServiceMethodPointcut() {}
	
	/**
	* Pointcut that selects join points being public method executions.
	*/
	@Pointcut("execution(public * *(..))")
	public void publicMethodPointcut() {}
	
	/**
	* Pointcut that selects join points within the package se.ivankrizsan.spring
	* and sub-packages.
	*/
	@Pointcut("within(se.ivankrizsan.spring..*)")
	public void inSpringPackagePointcut() {}
	
	/**
	* Pointcut that selects join points on the Spring bean with the
	* name "mySuperService".
	*/
	@Pointcut("bean(mySuperService)")
	public void mySuperServiceSpringBeanPointcut() {}
	
	/**
	* Pointcut that combines all the above pointcuts to select join points
	* that match all the pointcuts.
	*/
	@Pointcut("publicMethodPointcut() && inSpringPackagePointcut() && applicationServiceMethodPointcut() && mySuperServiceSpringBeanPointcut()")
	public void publicServiceMethodInSpringPackagePointcut() {}
	
	/**
	* Around advice that prints a string before and after execution of a
	* join point (typically a method).
	*
	* @param inProceedingJoinPoint Join point advised by around advice.
	* @return Result from the join point invocation.
	* @throws Throwable If exception thrown when executing join point.
	*/
	@Around("publicServiceMethodInSpringPackagePointcut()")
	public Object loggingAdvice(final ProceedingJoinPoint inProceedingJoinPoint) throws Throwable {
		System.out.printf("* Before service method '%s' invocation.%n", inProceedingJoinPoint.getSignature().toShortString());
		
		/* Invoke the join point. */
		final Object theResult = inProceedingJoinPoint.proceed();
		System.out.printf("* After service method '%s' invocation.%n", inProceedingJoinPoint.getSignature().toShortString());
		
		return theResult;
	}
}

Proxies

• Proxy classes are created in the init phase by dedicated BeanPostProcessors
• Two types of proxies
  • JDK dynamic proxies - creates a proxy object that implements all the interfaces implemented by the object to be proxied.
    • @EnableAspectJAutoProxy
    • Can only proxy by interface
    • Proxied bean must implement java interface
    • Part of JDK
    • All interfaces implemented by the class are proxied
    • Based on proxy implementing interfaces
    • Any methods found in the target object but not in any interface implemented by the target object cannot be proxied.
  • CGLib proxies - creates a subclass of the class of the object to be proxied.
    • @EnableAspectJAutoProxy(proxyTargetClass = true)
    • third-party library
    • The CGLIB proxy mechanism will be used by Spring AOP when the Spring bean for which to create a proxy does not implement any interfaces.
    • Can create a proxy by subclassing. In this scenario the proxy becomes a subclass of the target class. No need for interfaces.
    • Is not part of JDK, included in spring
    • Used when class implements no interface
    • Cannot be applied to final classes or methods
    • Based on proxy inheriting the base class
    • Spring AOP can use CGLIB proxies whether the target object implements an interface or not.

• The default type of proxy used by the Spring framework is the JDK dynamic proxy.
• Proxies limitations:
  • JDK Dynamic Proxies
    • Does not support self-invocations.
    • Class for which a proxy is to be created must implement an interface.
    • Only public methods in implemented interfaces will be proxied.
  • CGLIB Proxies
    • Does not support self-invocations.
    • Class for which a proxy is to be created must not be final.
    • Method(s) in class for which a proxy is to be created must not be final.
    • Only public and protected methods will be proxied.
    • Requires a third-party library.
      • Not built into the Java language and thus require a library.
      • The CGLIB library has been included into Spring, so when using the Spring framework, no additional library is required.
• To enable detection of Spring beans implementing advice which implementation classes are annotated with the @Aspect annotation, the @EnableAspectJAutoProxy annotation should be applied to a @Configuration class and aspects must be annotated with @Component similar to functionality found in Spring’s XML element.
• To enable @AspectJ support with Java @Configuration add the @EnableAspectJAutoProxy annotation
• When using the @EnableAspectJAutoProxy annotation, the aspectjweaver.jar library from AspectJ needs to be on the classpath.
• AOP is not the part of spring core container.

@Configuration
@EnableAspectJAutoProxy
public class AppConfig {

}

• When using proxies, suppose method a() calls method b() on the same class/interface, advice will never be executed for method b()

@Aspect
@Component
public class UserRepoMonitor {
    
    @Before("execution(public com.ps.repos.˙JdbcTemplateUserRepo+.findById(..))")
    public void beforeFindById(JoinPoint joinPoint) {
        String methodName = joinPoint.getSigTestJdbcTemplateUserReponature().getName();
        System.out.println(" ---> Method " + methodName + " is about to be called");
    }
}

• The @Before annotation is used with a parameter that is called a pointcut expression.
  This is used to identify the method execution on which the behavior will be applied.

@Configuration
@ComponentScan(basePackages = {"com.ps.repos.impl","com.ps.aspects"})
@EnableAspectJAutoProxy
public class AppConfig {
	
}

• @EnableAspectJAutoProxy- to enable aspect support, the configuration class must be annotated, default JDK dynamic proxy.
• @EnableAspectJAutoProxy(proxyTargetClass = true) - if the CGLIB library is to be added to the application classpath, Spring must be told that we want subclass-based proxies by modifying the aspect enabling annotation
  • This approach is suitable when the target class does not implement any interface, so Spring will create a new class on the fly that is a subclass of the target class
  • CGLIB is suitable for that because it is a bytecode generation library.
• It is obvious that the before advice was executed, but how does it actually work? Spring IoC creates the userTemplateRepo bean. Then the aspect definition with an advice that has to be executed before the findById method tells Spring that this bean has to be wrapped up in a proxy object that will add additional behavior, and this object will be injected instead of the original everywhere needed. And because we are using JDK dynamic proxies, the proxy will implement the UserRepo interface

• In order to use aspects in a Spring application you need the following:
  • spring-aop as a dependency
  • declare an @Aspect class and declare it as a bean as well (using @Component or @Bean or XML typical bean declaration element)
  • declare an advice method annotated with a typical advice annotation (@Before, @After, etc.) and associate it to a pointcut expression
  • enable aspects support by annotating a configuration class with @EnableAspectJAutoProxy
  • (optional) add CGLIB as a dependency and enable aspects support using subclassed proxies by annotating a configuration class with @EnableAspectJAutoProxy(proxyTargetClass = true)

Defining Pointcuts

• Pointcuts can be combined using the logical operators && (and),

  (or) and ! (not)

• The template that a pointcut expression follows can be defined as follows:

execution( [Modifiers] [ReturnType] [FullClassName].[MethodName] ([Arguments]) throws [ExceptionType])

• The expression can contain wildcards like + and * and can be made of multiple expressions concatenated by boolean operators such as &&(and),

  (or), !(not) etc.

  • The * wildcard replaces any group of characters
  • The + wildcard is used to specify that the method to advise can also be found in subclasses identified by [FullClassName] criteria.
  • !within(se.ivankrizsan.spring..*) - will result in join points that are NOT within the package se.ivankrizsan.spring or any of its subpackages being selected.
  • • • Matches types (return and argument types), whole or partial names (package, class, method).
  • .. - Matches zero or more arguments or packages.
• There is also a list of designators that can be used to define the reach of the pointcut; for example, the within(...) designator can be used to limit the pointcut to a package

public * com.ps.repos.*.JdbcTemplateUserRepo+.findById(..)) && +underlinewithin(com.ps.*)

• Pointcut expression can identify only methods defined in a class annotated with a specific annotation:

execution(@org.springframework.transaction.annotation.Transactional public * com.ps.repos.*.*Repo+.findById(..)))

• Pointcut expression can even identify methods that return values with a specific annotation:

execution(public (@org.springframework.stereotype.Service *) *(..)) 

• by using the @annotation() designator, only methods annotated with a specific annotation can be taken into consideration:

execution(public (public * com.ps.service.*.*Service+.*(..) && @annotation(org.springframework.security.access.annotation.Secured))

Pointcut Designators

• If using an unsupported AspectJ pointcut designator with Spring AOP, an IllegalArgumentException will be thrown.
• Pointcut designator: execution
  • The execution pointcut designator matches method execution join points.
    • Method visibility
      Can be one of private, protected, public. Can be negated using !. May be omitted, in which case all method visibilities will match.
    • Return type
      Object or primitive type. Can be negated with !. Wildcard * can be used, in which case all return types will be matched.
    • Package
      Package in which class(es) is/are located. May be omitted. Wildcard .. may be used last in package name to include all sub-packages. Wildcard * may be used in package name.
    • Class
      Class in which method(s) to be selected is/are located. May be omitted. Includes subclasses of the specified class. Wildcard * may be used.
    • Method
      Name of method(s) in which join points to be selected are located. Whole or partial method name. Wildcard * may be used, for example “gree*” will match a method named greet and any other methods which names start with “gree”.
    • Parameters
      Object or primitive types of parameters. A parameter-type can be negated with !, that is !int will match any type except for int. The wildcard .. can be used to match zero or more subsequent parameters.
    • Exceptions
      Type(s) of exception(s) that matching method(s) throws. An exception type can be negated using !.

execution(public String com.linnyk.spring.aopexamples.MySuperServiceImpl.*(String))

Pattern 
[method visibility] [return type] [package].[class].[method]([parameters] [throws exceptions])

• Pointcut designator: within
  • The within pointcut designator matches join points located in one or more classes, optionally specifying the package(s) in which the class(es) is/are located.
    • Package
      Package in which class(es) to be selected is/are located. May be omitted. Wildcard .. may be used last in package name to include all sub-packages. Wildcard * may be used in package name.
    • Class
      Class(es) in which join points are to be selected. Wildcard * may be used. Join points in subclasses of the specified class will also be matched.

within(se..MySuperServiceImpl)

Pattern
[package].[class]

• Pointcut designator: this
  • The this pointcut designator matches all join points where the currently executing object is of specified type (class or interface).
  • The pattern specifying which join points to select only consists of a single type.
  • Wildcards can not be used in type names.
  • The below pointcut expression will match join points in proxy objects that implement the MySuperService interface.

this(MySuperService)

• Pointcut designator: target
  • The target pointcut designator matches all join point where the target object, for instance the object on which a method call is being made, is of specified type (class or interface).

target(MySuperServiceImpl)

• Pointcut designator: args
  • The args pointcut designator matches join points, in Spring AOP method execution, where the argument(s) are of the specified type(s).
    • The .. wildcard may be used to specify zero or more parameters of arbitrary type.
    • The * wildcard can be used to specify one parameter of any type.
    • Package information may be included in the pattern specifying which join points to select.
    • The below example selects join points where the arguments are two long integers.
    • The following example selects all join points where the arguments are of any type from the java.util package

args(long, long)

args(java.util.*)

• Pointcut designator: @target
  • The @target pointcut designator matches join points in classes annotated with the specified annotation(s).
  • The below example selects all join points in all classes annotated with the Spring @Service annotation.

    @target(org.springframework.stereotype.Service)
    

• Pointcut designator: @args
  • The @args pointcut designator matches join points where an argument type (class) is annotated with the specified annotation.
  • Note that it is not the argument that is to be annotated, but the class.

@args(com.linnyk.spring.aopexamples.CleanData)

• Pointcut designator: @within
  • The @within pointcut designator matches join points in classes annotated with specified annotation.

@within(org.springframework.stereotype.Service)

• Pointcut designator: @annotation
  • The @annotation pointcut designator matches join points in methods annotated with specified annotation.

@annotation(com.linnyk.spring.aopexamples.MySuperSecurityAnnotation)

• Pointcut designator: bean
  • This pointcut designator selects all join points within a Spring bean.
    • The wildcard * may be used in the pattern, making it possible to match a set of Spring beans with one pointcut expression.
  • The below pointcut will select all join points in the Spring bean named mySuperService.

bean(mySuperService)

Implementing Advice

Aspect = PointCut(Where the Aspect is applied) + Advice(What code is executed)

Before

• Executed before a join point.
  • Cannot prevent proceeding to the join point unless the advice throws an exception.
  • Examples:
    • Access control (security)
      Authorization can be implemented using before advice, throwing an exception if the current user is not authorized.
    • Statistics
      Counting the number of invocations of a join point.
• Before advice will, always proceed to the join point unless an execution is thrown from within the advice code.
• Using a JoinPoint parameter in an advice is optional.

@Before("com.ps.aspects.PointcutContainer.serviceUpdate(id, pass)")
public void beforeServiceUpdate (Long id, String pass) throws Throwable {
	//..
}

1. The proxy object receives the call destined for the target bean and calls first the advice method
2. If the advice method returns successfully, it then forwards the initial call to the target bean and forwards the result back to the caller.
3. If the advice method throws an exception, the exception gets propagated to the caller, and the target method is no longer executed

After Returning

• This type of advice is executed only if the target method executed successfully and does not end by throwing an exception.
  • Examples:
    • Statistics
      Counting the number of successful invocations of a join point.
    • Data validation
      Validating the data produced by the advised method.

@AfterReturning(value="execution (* com.ps.services.*Service+.update*(..))", returning = "result")
public void afterServiceUpdate(JoinPoint joinPoint, int result) throws Throwable {
	//..
}

After Throwing

• Executed after execution of a join point that resulted in an exception being thrown.
  • Examples:
    • Error handling
    • Statistics

@AfterThrowing(value="execution(* com.ps.services.*Service+.updateUsername(..))", throwing = "e")
public void afterBadUpdate(JoinPoint joinPoint, Exception e) throws Throwable {
	//..
}

After

• The after advice is executed after the target method regardless of how its execution ended, whether successfully or with an exception, and because of this, it is most suitable to use for auditing or logging.
  • Examples:
    • Releasing resources.
      As with finally-blocks in try-finally, the after (finally) advice is always executed after the completion of the join point and can thus ensure that resources are always released.

@After("execution(public * com.ps.repos.*.JdbcTemplateUserRepo+.updateUsername(..))")
public void afterFindById(JoinPoint joinPoint) throws Throwable {
	//..
}

Around

• Around advice is the most powerful of the advice types.
• Around advice can be used for all of the use-cases for AOP
• Can chose to execute the join point or not.
• Can chose to return any return value from the execution of the join point or return some other return value.
• Executed before and after (around) a join point.
• The around advice is the most powerful type of advice, because it encapsulates the target method and has control over its execution, meaning that the advice decides whether the target method is called, and if so, when.
• The type ProceedingJoinPoint inherits from JoinPoint and adds the proceed() method that is used to call the target method

@Around("execution(public * com.ps.repos.*.*Repo+.find*(..))")
public Object monitorFind( ProceedingJoinPoint joinPoint) throws Throwable {
	long t1 = System.currentTimeMillis();
	Thread.sleep(1000L);
	return joinPoint.proceed();
	long t2 = System.currentTimeMillis();
	logger.info(" ---> Execution of " + methodName + " took: "   + (t2 - t1) / 1000 + " ms.");
}

JoinPoint

• JoinPoint can be added to methods implementing the following types of advice:
  • Before
  • After returning
  • After throwing
  • After
• The parameter must, if present, be the first parameter of the advice method.
• When the advice is invoked, the parameter will hold a reference to an object that holds static information about the join point as well as state information.
  • Examples of static information:
    • Kind (type) of join point
    • Signature at the join point
  • Examples of dynamic information available from the JoinPoint object:
    • Target object - JoinPoint.getTarget
    • Currently executing object

ProceedingJoinPoint

• Use of the ProceedingJoinPoint class as a parameter to an Around advice.
• This type is used as the first parameter of a method implementing an around advice.
• ProceedingJoinPoint class as a parameter to an around advice.
• ProceedingJoinPoint parameter, it will be impossible to invoke the next advice method or target method in such a case.
• ProceedingJoinPoint class is a subclass of the JoinPoint class it contains all the information described in the above section on the JoinPoint class.
• ProceedingJoinPoint class contains these two additional methods:
  • proceed()
    Proceed to invoke the next advice method or the target method without passing any parameters. Will return an Object. May throw a Throwable exception.
  • proceed(Object[] args)
    Proceed to invoke the next advice method or the target method passing an array of objects as argument to the method to be invoked. Will return an Object. May throw a Throwable exception.

@Around("publicServiceMethodInSpringPackagePointcut()")
public Object loggingAdvice(
	final ProceedingJoinPoint inProceedingJoinPoint) throws Throwable {
	System.out.printf("* Before service method '%s' invocation.%n", inProceedingJoinPoint.getSignature().toShortString());
	
	/* Invoke the join point. */
	final Object theResult = inProceedingJoinPoint.proceed();
	System.out.printf("* After service method '%s' invocation.%n", inProceedingJoinPoint.getSignature().toShortString());
	return theResult;
}

PointCuts

Wildcards

Parameter Wildcards

Packages and Classes

Annotation

Spring beans names as PointCut

Boolean expressions in PointCut

@PointCut

PointCuts XML

<aop:config>
    <aop:pointcut id="pointcut" expression="execution(void set*(*))"/> 
    
    <aop:aspect ref="myAspect">
        <aop:after-returning pointcut-ref="pointcut" method="logChange"/> 
    </aop:aspect> 
    
    <bean id="myAspect" class="com.example.MyAspect" />
</aop:config>

PointCuts Java

//Pointcut is referenced here by its ID
@Before("setters()") 
public void logChange() {
    //...
}

//Method name is pointcut id, it is not executed
@Pointcut("execution(void set*(*))") 
public void setters() {
    //...
}

Context Selection

public interface Server {
	public void start(Map input);
	public void stop();
}

Data Access

• DML stands for Data Manipulation Language, and the database operations presented so far are part of it, the commands SELECT, INSERT, UPDATE, and DELETE are database statements used to create, update, or delete data from existing tables.
• DDL stands for Data Definition Language, and database operations that are part of it are used to manipulate database objects: tables, views, cursors, etc. The commands CREATE, ALTER, DROP
• DataAccessException class and all of its subclasses in the Spring Framework.
  • All the exceptions in this exception hierarchy are unchecked.
  • The purpose of the data access exception hierarchy is isolate application developers from the particulars of JDBC data access APIs, for instance database drivers from different vendors.
  • This in turn enables easier switching between different JDBC data access APIs.
  • Its use helps convert proprietary checked exceptions, to a set of runtime exceptions.
  • Its use allows one to switch between persistence technologies fairly easily and it also allows one to code without worrying about catching exceptions that are specific to each technology.

• The javax.sql.DataSource interface is the interface from which all data-source classes related to SQL stem.
  • DelegatingDataSource
  • AbstractDataSource
  • SmartDataSource
  • EmbeddedDatabase
• DataSource in a standalone application

@Bean
public DataSource dataSource() {
	final BasicDataSource theDataSource = new BasicDataSource();
	theDataSource.setDriverClassName("org.hsqldb.jdbcDriver");
	theDataSource.setUrl("jdbc:hsqldb:hsql://localhost:1234/mydatabase");
	theDataSource.setUsername("ivan");
	theDataSource.setPassword("secret");
	return theDataSource;
}

• DataSource in Spring Boot, then it is not necessary to create a DataSource bean.
• Setting the values of a few properties are sufficient:

spring.datasource.url= jdbc:hsqldb:hsql://localhost:1234/mydatabase
spring.datasource.username=ivan
spring.datasource.password=secret

• DataSource in an application deployed to a server
  • If the application is deployed to an application server then a way to obtain a data-source is by performing a JNDI lookup

    @Bean
    public DataSource dataSource() {
    final JndiDataSourceLookup theDataSourceLookup = new JndiDataSourceLookup();
    final DataSource theDataSource =
    theDataSourceLookup.getDataSource("java:comp/env/jdbc/MyDatabase");
    return theDataSource;
    }
    

  • Spring Boot applications need only to rely on setting one single property:

    spring.datasource.jndi-name=java:comp/env/jdbc/MyDatabase
    

Java Config of DataSource and populating db

@Configuration
@Profile("dev")
@PropertySource("classpath:db/db.properties")
public class TestDataConfig {
	
	@Value("${driverClassName}")
	private String driverClassName;
	
	@Value("${url}")
	private String url;
	
	@Value("${username}")
	private String username;
	
	@Value("${password}")
	private String password;
	
	@Value("classpath:db/schema.sql")
	private Resource schemaScript;
	
	@Value("classpath:db/test-data.sql")
	private Resource dataScript;
        
    @Bean
    public static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer() {
      return new PropertySourcesPlaceholderConfigurer();
    }
    
    @Lazy
    @Bean
    public DataSource dataSource() {
        try {
            SimpleDriverDataSource dataSource = new SimpleDriverDataSource();
            Class<? extends Driver> driver = (Class<? extends Driver>) Class.forName(driverClassName);
            dataSource.setDriverClass(driver);
            dataSource.setUrl(url);
            dataSource.setUsername(username);
            dataSource.setPassword(password);
            DatabasePopulatorUtils.execute(databasePopulator(), dataSource);
            return dataSource;
        } catch (Exception e) {
            return null;
        }
    }
    
    @Bean
    public DataSourceInitializer dataSourceInitializer (final DataSource dataSource) {
        final DataSourceInitializer initializer = new DataSourceInitializer();
        initializer.setDataSource(dataSource);
        initializer.setDatabasePopulator(databasePopulator());
        return initializer;
    }
    
    private DatabasePopulator databasePopulator() {
        final ResourceDatabasePopulator populator = new ResourceDatabasePopulator();
        populator.addScript(schemaScript);
        populator.addScript(dataScript);
        return populator;
    }
    
    @Bean
    public JdbcTemplate userJdbcTemplate() {
        return new JdbcTemplate(dataSource());
    }
}

Embedded DataSource Java Configuration

• Especially useful for testing
• Supports H2, HSQL and Derby

@Configuration
@Profile("dev")
public class TestDataConfig {

    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
                .setType(EmbeddedDatabaseType.H2)
                .addScript("classpath:db/schema.sql")
                .addScript("classpath:db/test-data.sql")
                .build();
    }

}

Embedded DataSource XML Configuration

• Especially useful for testing
• Supports H2, HSQL and Derby

<jdbc:embedded-database id="dataSource">
	 <jdbc:script location="classpath:db/schema.sql"/>
	 <jdbc:script location="classpath:db/test-data.sql"/>
</jdbc:embedded-database>

Spring Cache

• The @Cacheable annotation is one of the most important and common annotation for caching the requests. If developers annotate a method with @Cacheable annotation and multiple requests are received by the application, then this annotation will not execute the method multiple times, instead, it will send the result from the cached storage
• The @CachePut annotation helps for updating the cache with the latest execution without stopping the method execution. The primary difference between the @Cacheable and the @CachePut annotation is that @Cacheable will skip running the method whereas @CachePut will actually run the method and then put its results in the cache
• Must specify a cache-manager

@Configuration
@ComponentScan("com.learning.linnyk")
@EnableCaching
public class AppConfig {

	@Bean
	public CacheManager cacheManager() {
		final SimpleCacheManager cacheManager = new SimpleCacheManager();
		cacheManager.setCaches(Arrays.asList(new ConcurrentMapCache("cities")));
		return cacheManager;
	}

}

• For each cache name, it creates a ConcurrentHashMap
• Third-party alternatives
  • Terracotta’s EhCache
  • Google’s Guava and Caffeine
  • Pivotal’s Gemfire

@Service
public class CitiesService {

	private CitiesRepository citiesRepository;

	@Autowired
	public CitiesService(CitiesRepository citiesRepository) {
		this.citiesRepository = citiesRepository;
	}

	@Cacheable(value = "cities") 
	public City getCityByIdCacheable(long id) {
		return citiesRepository.getCityById(id);
	}

	@CachePut(value = "cities")
	public City getCityByIdCachePut(long id) {
		return citiesRepository.getCityById(id);
	}
}

ACID

• Atomicity The changes within a transaction are either all applied or none applied. “All or nothing”
• Consistency Any integrity constraints, for instance of a database, are not violated.
• Isolation Transactions are isolated from each other and do not affect each other.
• Durability is the property of a transaction that should persist even in cases of power off, crashes, and other errors on the underlying system

Transactional Environment

• A transaction is an operation that consists of a number of tasks that takes place as a single unit – either all tasks are performed or no tasks are performed. If a task that is part of a transaction do not complete successfully, the other tasks in the transaction will either not be performed or, for tasks that have already been performed, be reverted.

• In a transactional environment, transactions have to be managed.
  In Spring, this is done by an infrastructure bean called the transaction manager.

• Configuring transactional behavior is done declaratively by annotating methods with @Transactional
• It is mandatory to use @Transactional on repository classes, too, in order to ensure transactional behavior
• Methods that need to be executed in a transactional context are annotated with @Transactional Spring annotation
• This annotation must be used only on public methods; otherwise, the transactional proxy won’t be able to apply the transactional behavior
• The standard javax.transaction.Transactional annotation is also supported as a drop-in replacement to Spring’s own annotation.

Difference between a local and a global transaction

• Global transactions allow for transactions to span multiple transactional resources. As an example consider a global transaction that spans a database update operation and the posting of a message to the queue of a message broker. If the database operation succeeds but the posting to the queue fails then the database operation will be rolled back (undone).

• Local transactions are transactions associated with one single resource, such as one single database or a queue of a message broker, but not both in one and the same transaction.

Configure Transactions Support

• Configure transaction management support
  • add a declaration of a bean of type org.springframework.jdbc.datasource.DataSourceTransactionManager
    • DataSourceTransactionManager class is a PlatformTransactionManager implementation for single JDBC datasources. It binds a JDBC connection from the specified data source to the currently executing thread, potentially allowing for one thread connection per data source.”
  • <tx:annotation-driven ../>

<bean id="transactionManager"
         class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
         <property name="dataSource" ref="dataSource"/>
</bean>

<tx:annotation-driven transaction-manager="transactionManager"/>

public class TestDataConfig {

    @Bean
    public PlatformTransactionManager txManager(){
        return new DataSourceTransactionManager(dataSource());
    }
}

• Apply the @EnableTransactionManagement annotation to exactly one @Configuration class in the application.
• @EnableTransactionManagement can be used so that the @Transactional in the code will work

@Configuration
@EnableTransactionManagement
@ComponentScan(basePackages = {"com.ps.repos.impl", "com.ps.services.impl"})
public class AppConfig {
    
}

• Declare transactional methods
  • Method that is to be executed in a transaction must be annotated with the Spring @Transaction annotation.

@Transactional
@Override
public User findById(Long id) {
	return userRepo.findById(id);
}

• The @Transactional annotation can be used at the class level too. In this case, all the methods in the class become transactional, and all properties defined for the transaction are inherited from the 1@Transactional1 class level definition,

• Both @EnableTransactionManagement and <tx:annotation-driven ../> enable all infrastructure beans necessary for supporting transactional execution. But there is a minor difference between them. The XML configuration element can be used like this: <tx:annotation-driven /> without the transaction-manager attribute. In this case, Spring will look for a bean named transactionManager by default, and if it is not found, the application won’t start. The @EnableTransactionManagement is more flexible; it looks for a bean of any type that implements the org.springframework.transaction.PlatformTransactionManager, so the name is not important.

@Transactional

• @Transactional annotation is used for declarative transaction management and can be used on class and method level both in classes and interfaces.
• In the Spring framework declarative transaction management is implemented using Spring AOP.

• When using Spring AOP proxies, only @Transactional annotations on public methods will have any effect – applying the @Transactional annotation to protected or private methods or methods with package visibility will not cause errors but will not give the desired transaction management,

• Parameters:
  • transactionManager - the transaction manager used to manage the transaction in the context of which the annotated method is executed.
  • readOnly - should be used for transactions that involve operations that do not modify the database (example: searching, counting records)
    • Allows Spring to optimize the transactional resource for read-only data access
    • Read-only transaction prevents Hibernate from flushing its session. Hibernate does not apply dirty checking thus it increases its performance
    • When JDBC transaction is marked as read-only, Oracle only accepts SELECT SQL statements.
  • propagation - transaction propagation. org.springframework.transaction.annotation.Propagation
  • isolation - the transaction isolation level. org.springframework.transaction.annotation.Isolation
  • timeout - value represents the number of milliseconds after which a transaction is considered failed,
  • rollbackFor - when this type of exception is thrown during the execution of a transactional method, the transaction is rolled back
  • rollbackForClassName - name of exception class(es) that are to cause a transaction rollback.
  • noRollbackFor - exception class(es) that never are to cause a transaction rollback.
  • noRollbackForClassName - names of exception class(es) that never are to cause a transaction rollback.

• Spring allows for using the JPA javax.transaction.Transactional annotation as a replacement for the Spring @Transactional annotation, though it does not have as many configuration options.
• If one @Transactional method call another @Transactional method, the method will execute in the same transaction context as the first.
• Declarative transaction management
  • This is accomplished using annotations or Spring XML configuration.
• Rollback police
  • The default rollback policy of Spring transaction management is that automatic rollback only takes place in the case of an unchecked exception being thrown.
  • The types of exceptions that are to cause a rollback can be configured using the rollbackFor element of the @Transactional annotation. In addition, the types of exceptions that not are to cause rollbacks can also be configured using the noRollbackFor element.
  • If a test-method annotated with @Test is also annotated with @Transactional, then the test-method will be executed in a transaction. Such a transaction will automatically be rolled back after the completion of the test-method.
    • The rollback policy of a test can be changed using the @Rollback annotation and setting the value to false.
• Target object wrapped in a proxy
  • Uses an Around advice
• Proxy implements the following behavior
  • Transaction started before entering the method
  • Commit at the end of the method
  • Rollback if method throws
    • java.lang.RuntimeException
    • unchecked exception
    • java.lang.Error
• By default, a transaction is rolled back if a RuntimeException has been thrown
• @Transactional("myOtherTransactionManager") - runs a transaction with specific transaction managers

PlatformTransactionManager

• PlatformTransactionManager is the base interface for all transaction managers that can be used in the Spring framework’s transaction infrastructure.
  • PlatformTransactionManager interface contain the following methods:
    • void commit(TransactionStatus)
    • void rollback(TransactionStatus)
    • TransactionStatus getTransaction(TransactionDefinition)

Using the PlatformTransactionManager

• The transaction name can be explicitly set only programmatically.

DefaultTransactionDefinition def = new DefaultTransactionDefinition();
// explicitly setting the transaction name is something that can only be done programmatically
def.setName("SomeTxName");
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);

TransactionStatus status = txManager.getTransaction(def);
try {
    // execute your business logic here
}
catch (MyException ex) {
    txManager.rollback(status);
    throw ex;
}
txManager.commit(status);

Programmatic Transactions using TransactionTemplate

• Example 1

• Example 2

@Service
public class ProgramaticUserService implements UserService {

    private UserRepo userRepo;

    private TransactionTemplate txTemplate;

    @Autowired
    public ProgramaticUserService(UserRepo userRepo, PlatformTransactionManager txManager) {
        this.userRepo = userRepo;
        this.txTemplate = new TransactionTemplate(txManager);
    }

    @Override
    public int updatePassword(Long userId, String newPass) throws MailSendingException {
        return txTemplate.execute(status -> {
            try {
                int result = userRepo.updatePassword(userId, newPass);
                User user = userRepo.findById(userId);
                String email = user.getEmail();
                sendEmail(email);
                return result;
            } catch (MailSendingException e) {
                status.setRollbackOnly();
            }
            return 0;
        });
    }
}

@EnableTransactionManagement

• @EnableTransactionManagement annotation is to annotate exactly one configuration class in an application in order to enable annotation-driven transaction management using the @Transactional annotation.
  • Components registered when the @EnableTransactionManagement annotation is used are:
    • TransactionInterceptor.
      • Intercepts calls to @Transactional methods creating new transactions as necessary etc.
      • Spring’s declarative transaction uses the TransactionInterceptor class in its AOP proxies in applying transactional advice.
    • A JDK Proxy or AspectJ advice.
      This advice intercepts methods annotated with @Transactional (or methods that are located in a class annotated with @Transactional).
  • @EnableTransactionManagement annotation have the following three optional elements:
    • mode
      Allows for selecting the type of advice that should be used with transactions. Possible values are AdviceMode.ASPECTJ and AdviceMode.PROXY with the latter being the default.
    • order
      
      Precedence of the transaction advice when more than one advice is applied to a join-point. Default value is Ordered.LOWEST_PRECEDENCE.
    • proxyTargetClass
      True of CGLIB proxies are to be used, false if JDK interface-based proxies are to be used in the application

Transaction Propagation

• Happens when code from one transaction calls another transaction
• Transaction propagation says whether everything should be run in single transaction or nested transactions should be used
• There are 7 levels of propagation
• 2 Basic ones - REQUIRED and REQUIRES_NEW

org.springframework.transaction.annotation.Propagation

• REQUIRED: an existing transaction will be used or a new one will be created to execute the method annotated with @Transactional(propagation = Propagation.REQUIRED).
• REQUIRES_NEW: a new transaction is created to execute the method annotated with @Transactional(propagation = Propagation.REQUIRES_NEW). If a current transaction exists, it will be suspended.
• NESTED: an existing nested transaction will be used to execute the method annotated with @Transactional(propagation = Propagation.NESTED). If no such transaction exists, it will be created.
• MANDATORY: an existing transaction must be used to execute the method annotated with @Transactional(propagation = MANDATORY). If there is no transaction to be used, an exception will be thrown.
• NEVER: methods annotated with @Transactional(propagation = Propagation.NEVER) must not be executed within a transaction. If a transaction exists, an exception will be thrown.
• NOT_SUPPORTED: no transaction is used to execute the method annotated with @Transactional(propagation = Propagation.NOT_SUPPORTED). If a transaction exists, it will be suspended.
• SUPPORTS: an existing transaction will be used to execute the method annotated with @Transactional(propagation = Propagation.SUPPORTS). If no transaction exists, the method will be executed anyway, without a transactional context.

Isolation Levels

• Transaction isolation in database systems determine how the changes within a transaction are visible to other users and systems accessing the database prior to the transaction being committed.
• 4 isolation levels available (from least strict to the most strict)
  • READ_UNCOMMITTED
  • READ_COMMITTED
  • REPEATABLE_READ
  • SERIALIZABLE
• Not all isolation levels may be supported in all databases
• Different databases may implement isolation is slightly different ways

org.springframework.transaction.annotation.Isolation

• DEFAULT: the default isolation level of the DBMS.
• READ_UNCOMMITED: data changed by a transaction can be read by a different transaction while the first one is not yet committed, also known as dirty reads. Dirty reads may occur.
• READ_COMMITTED: dirty reads are not possible when a transaction is used with this isolation level. This is the default strategy for most databases. But a different phenomenon could happen here: repeatable read: when the same query is executed multiple times, different results might be obtained. (Example: a user is extracted repeatedly within the same transaction. In parallel, a different transaction edits the user and commits. If the first transaction has this isolation level, it will return the user with the new properties after the second transaction is committed.) Phantom reads and non-repeatable reads can occur.
• REPEATABLE_READ: this level of isolation does not allow dirty reads, and repeatedly querying a table row in the same transaction will always return the same result, even if a different transaction has changed the data while the reading is being done. The process of reading the same row multiple times in the context of a transaction and always getting the same result is called repeatable read. Phantom reads can occur.
• SERIALIZABLE: this is the most restrictive isolation level, since transaction are executed in a serialized way. So no dirty reads, no repeatable reads, and no phantom reads are possible. A phantom read happens when in the course of a transaction, execution of identical queries can lead to different result sets being returned.

READ_UNCOMMITTED

• @Transactional (isolation=Isolation.READ_UNCOMMITTED)
• The lowest isolation level
• Dirty reads can occur - one transaction may be able to see uncommitted data of other transaction
• May be viable for large transactions or frequently changing data

READ_COMMITTED

• @Transactional (isolation=Isolation.READ_COMMITTED)
• Default isolation strategy for many databases
• Other transactions can see data only after it is properly committed
• Prevents dirty reads

REPEATABLE_READ

• @Transactional (isolation=Isolation.REPEATABLE_READ)
• Prevents non-repeatable reads - when a row is read multiple times in a single transaction, its value is guaranteed to be the same

SERIALIZABLE

• @Transactional (isolation=Isolation.SERIALIZABLE)
• Prevents phantom reads
  • The serializable isolation level will lock the entire range, for both reading and writing by other transactions – a so-called range-lock.

Testing transactional methods

• If a test-method annotated with @Test is also annotated with @Transactional, then the test-method will be executed in a transaction.
  Such a transaction will automatically be rolled back after the completion of the test-method.
  • No need to clean up your database after testing!
• The rollback policy of a test can be changed using the @Rollback annotation and setting the value to false.
• The @Sql annotation can be used to specify SQL scripts to be executed against a given database during integration tests.
• The @SqlGroup annotation can be used on classes and methods to group together @Sql annotations.
• The @SqlConfig is used to specify the configuration of the SQL script.

@Test
@Sql(statements = {"drop table NEW_P_USER if exists;"})
 public void testCreateTable(){
	 int result = userRepo.createTable("new_p_user");
	 assertEquals(0, result);
 }

@Test
@SqlGroup({
		@Sql(
				value = "classpath:db/extra-data.sql",
				config = @SqlConfig(encoding = "utf-8", separator = ";", commentPrefix = "--")
		),
		@Sql(
				scripts = "classpath:db/delete-test-data.sql",
				config = @SqlConfig(transactionMode = SqlConfig.TransactionMode.ISOLATED),
				executionPhase = Sql.ExecutionPhase.AFTER_TEST_METHOD
		)
})
public void testCount() {
	int count = userService.countUsers();
	assertEquals(8, count);
}   

@Sql

@Commit

• The TestContext framework can be instructed to cause the transaction to commit instead of roll back via the @Commit annotation

@BeforeTransaction

Spring JDBC

• Spring’s JdbcTemplate
  • Greatly simplifies use of the JDBC API
    • Eliminates repetitive boilerplate code
    • Alleviates common causes of bugs
    • Handles SQLExceptions properly
  • Without sacrificing power
    • Provides full access to the standard JDBC constructs
• After getting configured, instances of the JdbcTemplate class are threadsafe.
• It is thread-safe to inject a single configured instance of a JdbcTemplate reference into multiple DAOs.
• JdbcTemplate has a property whose type is DataSource.
• JdbcTemplate class is a Spring class that simplifies the use of JDBC by implementing common workflows for querying, updating, statement execution
  • Instances of JdbcTemplate are thread-safe after they have been created and configured
  • JdbcTemplate acquire and release a database connection for every method called.
  • JdbcTemplate callback
    • ResultSetExtractor - allows for processing of an entire result set, possibly consisting multiple rows of data, at once.
      • Note that the extractData method in this interface returns a Java object.
    • RowCallbackHandler - allows for processing rows in a result set one by one typically accumulating some type of result.
      • Note that the processRow method in this interface has a void return type.
    • RowMapper - allows for processing rows in a result set one by one and creating a Java object for each row.
      • Note that the mapRow method in this interface returns a Java object. -JdbcTemplate methods
    • batchUpdate
    • execute
    • query - uses for insert update delete
    • queryForList
    • queryForMap
    • queryForObject
    • queryForRowSet
    • update
• JdbcTemplate acquire and release a database connection for every method called.
• SimpleJdbcCall class can be used to call Stored Procedures in spring.

• jdbcTemplate.update uses for insert update delete

• Declare in spring-context.xml

	<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"
		  p:driverClassName="${driverClassName}"
		  p:url="${url}"
		  p:username="${username}"
		  p:password="${password}"
	/>

	<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate" p:dataSource-ref="dataSource"/>

Inject into repository

jdbcTemplate.update("insert INTO RIDE(NAME, DURATION) values (?, ?)", ride.getName(), ride.getDuration());

Select

jdbcTemplate.query("SELECT * FROM MY_TABLE", new RowMapper());

jdbcTemplate.queryForObject("SELECT * FROM MY_TABLE WHERE ID = id", new RowMapper());

Insert

jdbcTemplate.update(
			"insert INTO MY_TABLE(NAME, DURATION) values (?, ?)",
			obj.getName(), obj.getDuration());

Update

jdbcTemplate.update("UPDATE MY_TABLE set NAME = ?, DURATION = ? where id = ?",
			obj.getName(), obj.getDuration(), obj.getId());

Delete

jdbcTemplate.update("delete from MY_TABLE where id = ?", id);

Execute

• You can use the execute(..) method to execute any arbitrary SQL, and as such the method is often used for DDL statements.
• It can execute SQL insert statements.
• It can execute SQL delete statements.
• Invokes a simple stored procedure
  • this.jdbcTemplate.update("call SUPPORT.REFRESH_ACTORS_SUMMARY(?)", Long.valueOf(unionId));
• It is heavily overloaded with variants taking callback interfaces, binding variable arrays, and so on.

this.jdbcTemplate.execute("create table mytable (id integer, name varchar(100))");

Callback Interfaces

• RowMapper - best choice when each row of a ResultSet maps to a domain object
• RowCallbackHandler - best choice when no value should be returned from the callback method for each row, especially large queries
• ResultSetExtractor - best choice when multiple rows of a ResultSet map to a single object

RowMapper

• Spring provides a RowMapper interface for mapping a single row of a ResultSet to an object
• Allows for processing rows in a result set one by one and creating a Java object for each row.

public interface RowMapper<T> {
	T mapRow(ResultSet rs, int rowNum) throws SQLException;
}

• Querying and populating a single domain object:

Actor actor = this.jdbcTemplate.queryForObject(
      "select first_name, last_name from t_actor where id = ?",
      new Object[]{1212L},
      new RowMapper<Actor>() {
          public Actor mapRow(ResultSet rs, int rowNum) throws SQLException {
              Actor actor = new Actor();
              actor.setFirstName(rs.getString("first_name"));
              actor.setLastName(rs.getString("last_name"));
              return actor;
          }
      });

• Querying and populating a number of domain objects:

List<Actor> actors = this.jdbcTemplate.query(
      "select first_name, last_name from t_actor",
      new RowMapper<Actor>() {
          public Actor mapRow(ResultSet rs, int rowNum) throws SQLException {
              Actor actor = new Actor();
              actor.setFirstName(rs.getString("first_name"));
              actor.setLastName(rs.getString("last_name"));
              return actor;
          }
      });

RowCallbackHandler

• It extracts values from each row of a ResultSet.
• Spring provides a simpler RowCallbackHandler interface when there is no return object
  • Streaming rows to a file
  • Converting rows to XML
  • Filtering rows before adding to a Collection

public interface RowCallbackHandler {
	void processRow(ResultSet rs) throws SQLException;
}

ResultSetExtractor

• Spring provides a ResultSetExtractor interface for processing an entire ResultSet at once
  • You are responsible for iterating the ResultSet
• Suitable when more than a single row of data is needed to create a Java object holding query result data.

public interface ResultSetExtractor<T> {
	T extractData(ResultSet rs) throws SQLException, DataAccessException;
}

Querying for Generic Maps

In-Memory Database

@Bean
public DataSource dataSource() {
    EmbeddedDatabaseBuilder builder = new EmbeddedDatabaseBuilder();
    builder.setName("inmemorydb")
           .setType(EmbeddedDatabaseType.HSQL) 
           .addScript("classpath:/inmemorydb/schema.db") 
           .addScript("classpath:/inmemorydb/data.db");
    
           return builder.build();
}

The same in XML

<jdbc:embedded-database id="dataSource" type="HSQL"> 
    <jdbc:script location="classpath:schema.sql" /> 
    <jdbc:script location="classpath:data.sql" />
</jdbc:embedded-database>

Initialise db

<jdbc:initialize-database data-source="dataSource"> 
    <jdbc:script location="classpath:schema.sql" /> 
    <jdbc:script location="classpath:data.sql" />
</jdbc:initialize-database>

• EmbeddedDatabaseBuilder automatically run data.sql and schema.sql scripts from resources folder

Spring and Hibernate

• org.springframework.orm.hibernate5.LocalSessionFactoryBuilder
• org.hibernate.SessionFactory
• org.hibernate.Session
• org.springframework.orm.hibernate4.HibernateTransactionManager

Hibernate proper

• hibernate.dialect - the value is a dialect class matching the database used in the application
• hibernate.hbm2ddl.auto - the value represents what Hibernate should do when the application starts
• hibernate.format_sql - the generated SQL statements are printed to the console in a pretty and readable way.
• hibernate.show_sql - if true, all the generated SQL statements are printed to the console.
• hibernate.use_sql_comments - if true, Hibernate will put a comment inside the SQL statement to tell the developer what that statement is trying to do.

Spring + Hibernate Java configuration

• Inject database params and use them when create beans

@Value("${driverClassName}")
private String driverClassName;
@Value("${url}")
private String url;
@Value("${login}")
private String username;
@Value("${password}")
private String password;

• Create dataSource

@Bean
public DataSource dataSource() {
	final DriverManagerDataSource dataSource = new DriverManagerDataSource();
	dataSource.setDriverClassName(driverClassName);
	dataSource.setUrl(url);
	dataSource.setUsername(username);
	dataSource.setPassword(password);
	return dataSource;
}

• Create sessionFactory

@Bean
public Properties hibernateProperties() {
	final Properties hibernateProp = new Properties();
	hibernateProp.put("hibernate.dialect", "org.hibernate.dialect.H2Dialect");
	hibernateProp.put("hibernate.hbm2ddl.auto", "create-drop");
	hibernateProp.put("hibernate.format_sql", true);
	hibernateProp.put("hibernate.use_sql_comments", true);
	hibernateProp.put("hibernate.show_sql", true);
	return hibernateProp;
}

@Bean
public SessionFactory sessionFactory() {
	return new LocalSessionFactoryBuilder(dataSource())
			.scanPackages("com.ps.ents")
			.addProperties(hibernateProperties())
			.buildSessionFactory();
}