Intermediate Spring Matt Wheeler

This is a training NOT a presentation Please ask questions Notes This is a training NOT a presentation Please ask questions Prerequisites Introduction to Java Stack Basic Java and XML skills Introduction to Spring Introduction to Spring Part 2 Installed LdsTech IDE (or other equivalent) A few disclaimers to get things started

XML Schema-based Configuration (namespace handlers) Lifecycle hooks Review Bean lifecycle XML Schema-based Configuration (namespace handlers) Lifecycle hooks Bean Initialization (JSR 250, @PostConstruct, …) Bean post processors Component scanning Spring Component Annotations DI Annotations (JSR 330, @Inject, @Named)

Application Context web integration Testing framework Overview Advanced Injection Providers Spring EL Additional Injection Annotations Application Context web integration Testing framework Today we will be discussing some advanced injection techniques, including … We will talk about how to load a Spring context in a web environment And we will discuss Spring’s testing support

Providers facilitate (from the JavaDoc): Providers allow us to defer instantiation or accessing a resource until it is needed Providers facilitate (from the JavaDoc): Retrieving multiple instances Lazy or optimal retrieval of an instance Breaking circular dependencies Abstracting scope so you can look up an instance in a smaller scope from an instance in a containing scope If this does not make much sense yet, don’t worry, it will.

The result was something like the following Previous Training Lab We used the @Named annotation to select the prototypeRabbit to inject into the farm as the prize rabbit The result was something like the following Does anyone see any problem with this? @Component public class Farm { @Inject @Named("prototypeRabbit") private Rabbit prizeRabbit; … } In the last lab of our previous training , … What scope is the Farm? And what scope is the prizeRabbit?

Provider Demo DEMO Show that the meal count on the prototype rabbit injected into the farm increments Solve this using a provider

Allows access to Spring beans and properties Spring EL (SpEL) Allows access to Spring beans and properties Supports querying and manipulating object graph at runtime Similar syntax to Unified EL (but more extensive) Method invocation, string templating Namespace handlers use it to inject references into attributes For more specifics, please see the Spring docs: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html

We recommend only using this when necessary Spring EL Examples We recommend only using this when necessary For example When extracting a property from a map Or injecting a reference into a namespace handler <property name="someProperty" value="#{systemProperties['someValue']}" /> <jee:jndi-lookup id="databasePassword" jndi-name="dbPassword" /> <jee:jndi-lookup id="databaseUsername" jndi-name="dbUsername"/> <data-source driver-class="org.h2.Driver" url="jdbc:h2:mem:stack-starter;MODE=Oracle" user="#{databaseUsername}" password="#{databasePassword}" override="true" db-env="EMBEDDED"/> TODO: verify ??? Namespace handlers would have to have one attribute for a string reference and another for the actual bean reference, but Spring EL allows us to combine this and always use EL.

Additional Injection Annotations Many additional injection annotations Please refer to the Spring documentation here: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-annotation-config Annotation Example Description @Value @Value("#{someBean.someProperty}") private String something Spring EL can be used in correlation with @Value to inject a property @Resource private SomeBean someBean; Injects by name instead of type. Can inject Collections unlike @Named. If name not explicitly specified it uses the name of the property being annotated. Does not work with Provider. @Autowired Spring proprietary annotation almost equivalent to JSR 330 @Inject but with a required attribute. There are many addition injection annotations which can be used to inject values. @Value in correlation with SpEL can be utilized to inject properties. @Resource injects by name instead of type with some slight differences from the @Named annotation. Mostly used for injecting Collections. It has a nice feature that if no name is specified it uses the property name that is being annotated. @Autowired, is a Spring proprietary annotation that is almost exactly like @Inject, but adds the ability to specify a required attribute. Please see the Spring documentation for further specifics about these annotations.

https://tech.lds.org/wiki/Intermediate_Spring#Lab_1_Advanced_Injection Lab 1: Providers https://tech.lds.org/wiki/Intermediate_Spring#Lab_1_Advanced_Injection

Loading application context in a web environment Web Context Listener Loading application context in a web environment

Previously we have loaded application contexts with something like: Traditionally Previously we have loaded application contexts with something like: In a web environment however You will want the context to automatically be loaded on startup And be shared across the entire application ApplicationContext context = new ClassPathXmlApplicationContext("beans.xml"); SomeBean someBean = context.getBean(SomeBean.class);

The Java Servlet spec provides a listener (startup hook) Servlet Listeners The Java Servlet spec provides a listener (startup hook) Listeners triggered to run on startup Spring utilizes this functionality and has created a listener that will load the application context on start up

Context Loader Listener Here is the web.xml configuration: And utilizes the following context parameter <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:META-INF/spring/applicationContext.xml,classpath:*beans.xml</param-value> <param-value>classpath:anotherContext.xml</param-value> </context-param> Notice that the value for the param value can specify multiple comma delimited context locations, or multiple <param-value> elements, and can also use wildcards

Application Contexts and Servlets Servlets not instantiated by Spring Instantiated by the servlet container Spring unable to inject dependencies However Spring provides a way to access the application context Since this context gets loaded once per application and not every time it is utilized you might wonder how to access the context, or how injection works with servlets, … well in short it doesn’t really Since a servlet is not instantiated by Spring and must be instantiated by the servlet container Spring is unable to inject dependencies into a Servlet as it is not Spring managed. Accordingly the mechanism for getting spring beans in a servlet is as follows:

Application Context and Servlet For the given servlet configuration (web.xml) Application Context accessed as follows: <servlet> <servlet-name>servlet</servlet-name> <servlet-class>org.lds.training.TrainingServlet</servlet-class> </servlet> <servlet-mapping> <url-pattern>/servlet</url-pattern> </servlet-mapping> public class TrainingServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { //Context loader listener stores context in the servlet context - which is why it is required ApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(getServletContext()); SomeBean someBean = (SomeBean) applicationContext.getBean(SomeBean.class); someBean.printSomething(); } This partially reverts back to dependency lookup thus losing many of the niceties inherent in dependency injection. But as you might expect there is a better way.

A Better Way Spring provides a servlet that delegates to a bean that is Spring managed Called an HttpRequestHandler Allows annotations and injection Create a Spring bean that matches the name of the servlet name This provides the mapping between the two

Utilizing a Spring Request Handler The configuration: <!– web.xml --> <servlet> <servlet-name>trainingHandler</servlet-name> <servlet-class>org.springframework.web.context.support.HttpRequestHandlerServlet</servlet-class> </servlet> <servlet-mapping> <url-pattern>/trainingHandler</url-pattern> </servlet-mapping> @Component("trainingHandler") public class TrainingRequestHandler implements HttpRequestHandler { @Inject private SomeBean someBean; public void handleRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { someBean.printSomething(); } Notice that we create a servlet in web.xml just as we normally would but we specify Spring’s HttpRequestHandlerServlet as the class. This class delegates to a Spring bean that matches the servlet name, and which implements the HttpRequestHandler interface (i.e. the handleRequest method) //Note that the code in the servlet is in essence executed for you in the request handler <!– applicationContext.xml --> <bean id="trainingHandler" class="org.lds.training.TrainingRequestHandler" />

Spring MVC and Application Contexts Spring MVC provides and even better way to integrate with the web container Look forward to further discussion of this in a future training

Lab 2: Web Context Listener https://tech.lds.org/wiki/Intermediate_Spring#Lab_2_Web_Context_Listener

Spring promotes testing in two prominent ways Spring Testing Spring promotes testing in two prominent ways Making the code more testable Proving a testing framework

Dependency injection decouples code from the container Testable Code Dependency injection decouples code from the container POJOs are normally easier to test Dependencies are clearly defined Allows you to swap implementations As I mentioned in a previous training, it cannot be overstated how Spring helps testing, not just test framework integration but also testability

Testing Help Additionally we have an application context that can manage dependencies Reloading the context for each test could be time consuming and unnecessary Spring provides support to load the context once per JVM (unless you explicitly tell it to reload)

Many good testing frameworks available JUnit TestNG Spring provides a context loader for tests Currently Spring supports JUnit 3, JUnit 4, and TestNG We will be using TestNG Living up the their stated goal Spring has not written their own testing framework, but have rather just made integration with existing frameworks easy …. Lets look at an example.

@ContextConfiguration Spring Test Framework @ContextConfiguration Allows you to specify application contexts to load Important: Loaded in the order specified Later bean definitions of the same name will override earlier ones Allows us to utilize everything in the project context But selectively override bean definitions in the test contexts AbstractTestNGSpringContextTests @ContextConfiguration(locations={"classpath*:*beans.xml","classpath*:*beans-test.xml"}) public class FarmIT extends AbstractTestNGSpringContextTests { //… } Notice that annotating the class is not enough, you must also extend the AbstractTextNGSpringContextTests (or appropriate provider test context) as well. This configures listeners that actually handle the injection using the contexts specified in the @ContextConfiguration annotations The ability to override is very valuable. Say that you have a datasource in the real application that you don’t want to have to set up for tests – or say you would like to utilize an embedded database for tests. Or, assume that you have jndi properties in your real application. You don’t want to have to mimic those to run a test. These automatically register a couple of listeners DependencyInjectionTestExcecutionListener – which injects dependencies including application context DirtiesContextTestExecutionListener – handles @DirtiesContext annotations   Demo Show how by extending the DependencyInjectionTest… it handle all of the injection – and show that this only occurs once Show that the dirties context listener can be used to make it reload the context Show that you can get a bean through the inherited applicationContext or also through annotations

DEMO DEMO Show how by extending the test context class some listeners are set up that facilitate the injection

The application bean definition file For example The application bean definition file The test bean definition file <jee:jndi-lookup id="securityConnectionUrl" jndi-name="ldap/URL"/> <jee:jndi-lookup id="securityConnectionDN" jndi-name="ldap/DN"/> <jee:jndi-lookup id="securityConnectionPassword" jndi-name="ldap/Password"/> <bean id="securityConnectionUrl" class="java.lang.String"> <constructor-arg value="ldaps://gdirstage/" /> </bean> <bean id="securityConnectionDN" class="java.lang.String"> <constructor-arg value="cn=LDAP-STACK,ou=apps,o=lds" /> <bean id="securityConnectionPassword" class="java.lang.String"> <constructor-arg value="password1" /> Since the test context is loaded second, when the application looks for say securityConnectionUrl it will be found in the test context and returned instead of needing the jndi counterpart

Stack Utils namespace handler (stack-utils:null) Additionally, sometimes you would like the value to be null in a test This can be accomplished with a Stack provided Xml-schema based configuration For more information: http://code.lds.org/maven-sites/stack/module.html?module=spring-utils http://code.lds.org/maven-sites/stack/module.html?module=spring-utils/xsddoc/ <stack-util:null id="securityConnectionUrl" /> <stack-util:null id="securityConnectionDN" /> <stack-util:null id="securityConnectionPassword" />

Regular application context Another example Regular application context Test application context <stack-db:data-source jndi-name="jdbc/default/DataSource"/> <stack-db:data-source driver-class="org.h2.Driver" url="jdbc:h2:mem:stack-starter;MODE=Oracle" user="" password="" override="true" db-env="EMBEDDED"/> Namespace handle creates bean definitions and so the bean definitions will just override the other ones.

Testing with a Database Suppose you wanted to use a database to test Normally You would add data, run the test, and then clean it up Spring provides transactional support Data from the test automatically rolls back after the test Must extend AbstractTransactionalTestNGSpringContextTests Must specify a transaction manager in your bean definition Additional documentation: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/testing.html#testcontext-tx Along these lines, suppose …. You can get transaction support by extending the appropriate transactional test context for the given test framework – for instance AbstractTransactionalTestNGSpringContextTests I am largely showing you this so that you can see the current world record for longest class name.   //If you notice, this class is annotated with @Transactional making every method //transactional by default. If for any reason you don’t want a method //transactional you can mark it @NotTransactional //Talk about other common annotations such as //@ExpectedException //(repeat, timed, rollback) //Not that you must have a transaction manager specified in your bean definition //file. // Provides helpful methods like executeSqlScript (to set up and //environment)...

Spring Provides Useful Testing Stubs Lastly Spring provides many useful stub (mock objects) JNDI Servlet API These can save a lot of code and be more usable that dynamic mock objects For further information: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/testing.html#mock-objects

Lab 3: Spring Testing Integration https://tech.lds.org/wiki/Intermediate_Spring#Lab_3_Spring_Testing_Integration

Credit where credit is due http://springsource.org Spring Recipies 2nd Edition (Gary Mak, Josh Long and Daniel Rubio)