JavaBeat » Spring Framework

Annotation Support for Scheduling and Asynchronous Execution

Manisha Patil — Wed, 08 May 2013 16:04:02 +0000

In the previous post Task Execution and Scheduling in Spring, I explained basic interfaces for task execution and scheduling. In this post I shall demonstrate an example for the same using annotations @Scheduled and @Async. Let us have working Eclipse IDE in place and follow the steps to create a scheduled Spring application:

Create a project: Create a project with a name SpringScheduler and create a package com.javabeat under the src directory in the created project.
Add Libraries: Add required Spring libraries using Add External JARs option as explained in the article Customizing callback methods. Along with these libraries also add aopalliance-1.0.jar to the build path.
Create source files: Create Java classes SchedulerSample,TaskSample and MainApp under the com.javabeat package.
Create configuration file: Create XML based configuration file Beans.xml under src directory.

The content of SchedulerSample.java file are:

package com.javabeat;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

@Component
public class SchedulerSample {

	  @Autowired
	  private TaskSample task;

	  @Scheduled(fixedDelay = 3000)
	  public void processScheduledJob() {
	    task.execute();
	  }

	  public TaskSample getTask() {
	    return task;
	  }

	  public void setTask(TaskSample task) {
	    this.task = task;
	  }
}

Here you can note that we have scheduled the task for a time of 3000 milliseconds.

The content of TaskSample.java file are:

package com.javabeat;

import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Component;

@Component
public class TaskSample {
	@Async
	public void execute() {
		System.out
		.println("Executing asynchronous task for every fixedDelay of 3000millisecond.");
	}
}

The execute() method will be called every 3000 milliseconds.

The content of Beans.xml file are:

Here we need to note few things:

To enable the annotation driven scheduling we have added the annotation-driven element from the task namespace.
Schema http://www.springframework.org/schema/task, http://www.springframework.org/schema/task/spring-task-3.0.xsd, are added to the above file.
task:executor – creates an instance of ThreadPoolTaskExecutor.
task:scheduler – creates an instance of ThreadPoolTaskScheduler.

To execute the application the MainApp.java is as follows:

package com.javabeat;

import org.springframework.context.support.ClassPathXmlApplicationContext;

public class MainApp {
	public static void main(String[] args) {
	    new ClassPathXmlApplicationContext("Beans.xml");
	  }
}

Execute the code

The final step is run the application. Once all the above code is ready execute and the below output appears on the console:

Executing asynchronous task for every fixedDelay of 3000millisecond.
Executing asynchronous task for every fixedDelay of 3000millisecond.

As you can see the message is printed at a delay of 3000millisecond. You need to stop the application to stop the printing of message.

Summary

In this section I demonstrated an example of scheduling the Spring application using the annotation.If you are interested in receiving the future articles, please subscribe here. follow us on @twitter and @facebook

Task Execution and Scheduling in Spring

Manisha Patil — Wed, 08 May 2013 09:50:07 +0000

Connect to us ( @twitter | @facebook )

Spring 2.0 introduced abstractions for asynchronous execution and scheduling of tasks. The key interfaces for scheduling and task execution are as listed as TaskExecutor, TaskScheduler, Trigger, TriggerContext and ScheduledFuture. Let take a look at each of these interfaces. This article explores spring’s scheduler related APIs in detail. You can read the official explanation for this API’s here.

TaskExecutor

TaskExecutor was introduced as an abstraction for dealing with executors. Executors are the Java 5 name for the concept of thread pools. The primary aim of TaskExecutor is to abstract away the need for Java 5 when using thread pools. The interface has only a single method as shown below:

public interface TaskExecutor extends java.util.concurrent.Executor {
void execute(Runnable task);
}

TaskExecutor Implementation Classes

SimpleAsyncTaskExecutor: Does not reuse threads. It starts a new thread and is asynchronus.
SyncTaskExecutor: No thread reuse and is synchonous. Instead, each invocation takes place in the calling thread.
ConcurrentTaskExecutor: Exposes the Java 5 java.util.concurrent.Executor.
SimpleThreadPoolTaskExecutor: It is a subclass of Quartz’s SimpleThreadPool which listens to Spring’s lifecycle callbacks.
ThreadPoolTaskExecutor: It exposes bean properties for configuring a ThreadPoolExecutor configuration and and wraps it in a TaskExecutor.
TimerTaskExecutor: This implementation uses a single TimerTask as its backing implementation. It’s different from the SyncTaskExecutor in that the method invocations are executed in a separate thread, although they are synchronous in that thread.
WorkManagerTaskExecutor: This implementation uses the CommonJ WorkManager as its backing implementation

TaskScheduler

This interface has a variety of methods for scheduling tasks to run at some point in the future, as seen below:

public interface TaskScheduler {
ScheduledFuture schedule(Runnable task, Trigger trigger);

    ScheduledFuture schedule(Runnable task, Date startTime);

    ScheduledFuture scheduleAtFixedRate(Runnable task, Date startTime, long period);

    ScheduledFuture scheduleAtFixedRate(Runnable task, long period);

    ScheduledFuture scheduleWithFixedDelay(Runnable task, Date startTime, long delay);

    ScheduledFuture scheduleWithFixedDelay(Runnable task, long delay);
}

FixedRate – period will be measured from the start time
FixedDelay – period will be measured from the completion time

TaskScheduler Implementation Classes

TimerManagerTaskScheduler: Delegates to a CommonJ TimerManager instance, typically configured with a JNDI-lookup.
ThreadPoolTaskScheduler: Used whenever external thread management is not a requirement. Internally, it delegates to a ScheduledExecutorService instance.

Trigger

Using Trigger the execution times may be determined based on past execution outcomes or even arbitrary conditions. The Trigger interface is as follows:

public interface Trigger {
Date nextExecutionTime(TriggerContext triggerContext);
}

TriggerContext is an interface and encapsulates all of the relevant data.

Trigger Implementation Classes

CronTrigger: It enables the scheduling of tasks based on cron expressions.
PeriodicTrigger: It accepts a fixed period, an optional initial delay value, and a boolean to indicate whether the period should be interpreted as a fixed-rate or a fixed-delay.

Bootstrapping the scheduler

Since Spring 3.0, XML namespace for configuring TaskExecutor and TaskScheduler instances is available. It also provides a convenient way to configure tasks to be scheduled with a trigger. Add the following schema to the spring configuration file(xml file):


http://www.springframework.org/schema/task


http://www.springframework.org/schema/task/spring-task-3.0.xsd

Task Namespace
Add the following configuration :

task:executor – Create instance of ThreadPoolTaskExecutor
task:scheduler – Create instance of ThreadPoolTaskScheduler
pool-size – If the value is not provided, then the default thread pool will only have a single thread.
queue-capacity – Number of tasks held back. Default value is Unbound
rejection-policy – This another attribute not mentione the above example. Used for to throw exception when a task is rejected. Its default value is AbortPolicy. Other possbile values are – DiscardPolicy , DiscardOldestPolicy , and CallerRunsPolicy.

Scheduling the Tasks

Tasks can be scheduled in the following three ways:

Annotation Driven
XML Driven
Programmatically

1. Annotation Driven

The @Scheduled annotation can be added to a method along with trigger metadata for task scheduling. The @Async annotation can be provided on a method so that invocation of that method will occur asynchronously.

Add following to your spring configuration file:

The following example will only execute on weekdays.:

@Scheduled(cron="*/5 * * * * MON-FRI")
public void doSomeTask(){
 // some task that should execute on weekdays only
}

Scheduled methods must have void returns and must not expect any arguments.

Syntax for @Async annotation is:

@Async
void doSomething() {
    // this will be executed asynchronously
}

2. XML Driven

Add the following configuration to the spring configuration file :

3. Programmatically

Go for programmatic way when your application desire more control on scheduling. For example :


ThreadPoolTaskScheduler scheduler = (ThreadPoolTaskScheduler) appContext.getBean("scheduler");
CronTrigger trigger = new CronTrigger("*/5 * * * * MON-FRI");

ScheduledFuture scedulefuture= scheduler.schedule(taskObject, trigger );

In the above example instead of schedule() method, you can use scheduleAtFixedRate(.. , ..) or scheduleWithFixedDelay(.. , ..).

Summary

In this post we saw the basics of task execution and scheduling in Spring. We studied the interfaces TaskExecutor, TaskScheduler, and Trigger and their implementation classes. We also saw methods of scheduling the tasks, annotation driven, XML driven and programmatically. In the next article I shall demonstrate this with an example. If you are interested in receiving the future articles, please subscribe here. follow us on @twitter and @facebook.

Cache Abstraction In Spring (Example for @Cacheable and @CacheEvict)

Manisha Patil — Wed, 01 May 2013 13:39:20 +0000

Connect to us ( @twitter | @facebook )

Since Spring 3 a new abstraction layer for caching services has been introduced called Cache Abstraction. The idea is to provide a set of common features, mainly annotations, to activate and manage the caches. Cache Abstraction is nothing but applying caching to Java methods, reducing thus the number of executions based on the information available in the cache. That is, each time a targeted method is invoked, the abstraction will apply a caching behavior checking whether the method has been already executed for the given arguments.

If yes, then the cached result is returned without having to execute the actual method.
If no, then method is executed, the result cached and returned to the user so that, the next time the method is invoked, the cached result is returned.

As the name implies, Cache Abstraction is not an actual implementation. Hence it requires the use of an actual storage to store the cache data. Ehcache support is provided out of the box. There is also an implementation based on JDK’s ConcurrentMap and you can actually plug-in different back-end caches.

Annotation based Caching

For caching declaration, the abstraction provides following Java annotations:

@Cacheable: put the method returned value(s) into the cache.
@CacheEvict: remove an entry from the cache.
@CachePut: force a cache entry to be updated.
@Caching: @Caching allows multiple nested @Cacheable, @CachePut and @CacheEvict to be used on the same method.

Enable caching annotations

Caching feature needs to be declaratively enabled by using either of following ways:

Add the annotation @EnableCaching to one of your @Configuration classes.
Alternatively for XML configuration use the cache:annotation-driven element.

@Cacheable annotation

In Spring @Cacheable is useful in the case when a very complex code is running for many times. @Cacheable caches the result per input values of methods, so on subsequent invocations (with the same arguments), the value in the cache is returned without having to actually execute the method. Spring handles this functionality by second level cache. @Cacheable is used in the code as shown below:

@Cacheable("product")
public String getProduct(int productId){}

@CacheEvict annotation

The cache abstraction allows not just population of a cache store but also eviction i.e removes data from the cache. @CacheEvict in spring is used to evict cache value. @CacheEvict is applied on the method. This annotation has an extra parameter allEntries which indicates whether a cache-wide eviction needs to be performed rather then just an entry one (based on the key):

@CacheEvict(value = "product", allEntries=true)
public void setProduct(int productId){}

This option comes in handy when an entire cache region needs to be cleared out – rather then evicting each entry (which would take a long time since it is inefficient), all the entires are removed in one operation as shown above.

Example for @Cacheable and @CacheEvict

The following example demonstrates the use of the @Cacheable and @CacheEvict annotations and enabling them in the Spring application. Let us have working Eclipse IDE in place and follow the following steps to create a Spring application:

Create a project: Create a project with a name SpringCacheAbstraction and create a package com.javabeat under the src directory in the created project.
Add Libraries: Add required Spring libraries using Add External JARs option as explained in the article Customizing callback methods. Along with te specified JARs in the link, also add make sure these JARs are in the buildpath of the project:aopalliance-x.0.jar, ehcache-x.x.0.jar(you can download latest ehcache.jar from here: )
Create source files: Create Java classes Product,and MainApp under the com.javabeat package.
Create configuration file: Create XML based configuration file Beans.xml and ehcache.xml under src directory.

Contents of Product.java are as below:

package com.javabeat;

import org.springframework.cache.annotation.CacheEvict;
import org.springframework.cache.annotation.Cacheable;

public class Product {
	@CacheEvict(value = "prod", allEntries = true)
	public void setProduct(int productId) {
		System.out.println("execute setProduct method..");
	}

	@Cacheable("prod")
	public String getProduct(int productId) {
		System.out.println("execute getProduct method..");
		if (productId == 1) {
			return "Product A";
		} else {
			return "Product B";
		}
	}
}

Contents of MainApp.java are as below:

package com.javabeat;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class MainApp {
	public static void main(String... args) {
		AbstractApplicationContext context = new ClassPathXmlApplicationContext(
				"Beans.xml");
		Product product = (Product) context.getBean("product");

		// calling getProduct method first time.
		System.out.println(product.getProduct(1));

		// calling getProduct method second time. This time, method will not
		// execute.
		System.out.println(product.getProduct(1));

		// calling setProduct method to evict the cache value
		product.setProduct(1);

		// calling getProduct method third time. This time, method will execute
		// again.
		System.out.println(product.getProduct(1));
	}
}

There is a method getProduct in the class Product. We have called it three times. First time getProduct methods runs and sets result in cache named prod. Second time getProduct does not run because there is value in cache. Now call setProduct to remove the cache value. Again run getProduct method . This method will run because cache value is empty because of eviction.

Contents of Beans.xml are as below:

To get @Cacheable our result we have to configure org.springframework.cache.ehcache.EhCacheCacheManager in Beans xml as seen above. All second level configuration properties are configured in an ehcache.xml and that xml file is configured in Beans.xml as seen above.

Contents of ehcache.xml are as below:

Cache name has been declared as which is used in the Product.java class for caching result of the method.

Execute

Once all the code is ready, execute the MainApp class and if everythingis fine, the following output should appear on the console:

execute getProduct method..
Product A
Product A
execute setProduct method..
execute getProduct method..
Product A

Summary

In this post we saw the basics of Cache Abstraction in Spring. An example is used to demostrate the use of @Cacheable and @CacheEvict. In the next post I shall cover some other feature of the Spring. If you are interested in receiving the future articles, please subscribe here. follow us on @twitter and @facebook

Resources API in Spring – Part 2 (ResourceLoaderAware)

Manisha Patil — Mon, 29 Apr 2013 00:37:19 +0000

Connect to us ( @twitter | @facebook )

In the previous post I discussed about the external resource loading in Spring using Resource Loader interface, and setter methods. In this post I shall discuss about another form of resource loading through ResourceLoaderAware interface. Prior to release of Spring 2.5, this technique was used to load the external resources. Post Spring 2.5, you can rely upon autowiring of the ResourceLoader as an alternative to implementing the ResourceLoaderAware interface.

The ResourceLoaderAware interface is a special marker interface, identifying objects that expect to be provided with a ResourceLoader reference.

also read: follow us on @twitter and @facebook

Example for Using ResourceLoaderAware

The example below demonstrates the use of ResourceLoaderAware to load the external resources. Let us have working Eclipse IDE in place and follow the following steps to create a Spring application:

Create a project: Create a project with a name SpringExternalResourceExample and create a package com.javabeat under the src directory in the created project.
Add Libraries: Add required Spring libraries using Add External JARs option as explained in the article Customizing callback methods.
Create configuration file: Create XML based configuration file Beans.xml under src directory.
Create source files: Create Java classes MainApp and ProductService under the com.javabeat package.

Contents of ProductService.java are:

package com.javabeat;

import org.springframework.context.ResourceLoaderAware;
import org.springframework.core.io.Resource;
import org.springframework.core.io.ResourceLoader;

public class ProductService implements ResourceLoaderAware {

	private ResourceLoader resourceLoader;

	public void setResourceLoader(ResourceLoader resourceLoader) {
		this.resourceLoader = resourceLoader;
	}

	public Resource getResource(String location) {
		return resourceLoader.getResource(location);
	}
}

Contents of Beans.xml are:

Contents of MainApp.java are:

package com.javabeat;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.core.io.Resource;

public class MainApp {
	public static void main(String[] args) throws Exception {
		ApplicationContext ctx = new ClassPathXmlApplicationContext("Beans.xml");
		ProductService productService = (ProductService) ctx
				.getBean("productService");

		try {
			Resource resource = productService
					.getResource("file:c:\\SampleResourceFile.txt");
			InputStream is = resource.getInputStream();
			BufferedReader br = new BufferedReader(new InputStreamReader(is));

			String line;
			while ((line = br.readLine()) != null) {
				System.out.println(line);
			}
			br.close();

		} catch (IOException e) {
			e.printStackTrace();
		}

	}

}

We get the resource from the bean productService.

Now execute the code and the following output appears on the console:

**********************************
HI I'M AN EXTERNAL RESOURCE FILE
**********************************

Constructing application contexts

ApplicationContext is an interface only. You have to instantiate an implementation of it. An application context constructor (for a specific application context type) generally takes a string or array of strings as the location path(s) of the resource(s) such as XML files that make up the definition of the context. For example:

ApplicationContext ctx = new ClassPathXmlApplicationContext("com/javabeat/beans.xml");

The ClassPathXmlApplicationContext implementation builds an application context by loading an XML
configuration file from the classpath, when the location path doesn’t have a prefix. Besides ClassPathXmlApplicationContext, several other ApplicationContext implementations are provided by Spring. FileSystemXmlApplicationContext is used to load XML configuration files from the file system or from URLs, while XmlWebApplicationContext and XmlPortletApplicationContext can be used in web and portal applications only.

The classpath*: prefix

When constructing an XML-based application context, a location string may use the special classpath “*:” prefix: An example:

ApplicationContext ctx = new ClassPathXmlApplicationContext("classpath*:conf/appContext.xml");

The classpath*:conf/appContext.xml simply means that all appContext.xml files under conf folders in all your jars on the classpath will be picked up and joined into one big application context.

Summary

In this post we saw how to load resources using ResourceLoaderAware interface. We also saw how to construct the application contexts and use wild card in application context constructor using the classpath*: prefix.Please refer here for the official documentation on resource API. If you are interested in receiving the future articles, please subscribe here. follow us on @twitter and @facebook.

Resources API in Spring – Part 1

Manisha Patil — Sun, 28 Apr 2013 16:19:12 +0000

Connect to us ( @twitter | @facebook )

At times we may need to read external resources (e.g., text files, XML files, properties file, or image files) into our application. These resources can be located different locations (e.g., a file system, classpath, or URL). Usually, you have to deal with different APIs for loading resources from different locations. To handle such file accessing tasks, Spring provides an interface called as Resource contained in the package org.springframework.core.io. In this post I shall cover the details of Resource interface, loading of Resource using getResource() method, using Resource loader and through setter methods.

also read: follow us on @twitter and @facebook

Resource Interface

Contents of this interface are as shown below:

public interface Resource extends InputStreamSource {

    boolean exists();

    boolean isOpen();

    URL getURL() throws IOException;

    File getFile() throws IOException;

    Resource createRelative(String relativePath) throws IOException;

    String getFilename();

    String getDescription();
}

Contents of InputStreamSource are as below:

public interface InputStreamSource {

    InputStream getInputStream() throws IOException;
}

Resource is a general interface in Spring for representing an external resource.

Spring Built-in implementations for Resource interface

Spring provides several built-in implementations for the Resource interface as listed below:

UrlResource: Represents a URL.
ClassPathResource: Represents a File loaded from the classpath.
FileSystemResource: Represents a File.
ServletContextResource: This implementation is for ServletContext resources, interpreting relative paths within the relevant web application’s root directory.
InputStreamResource: Represents an input stream.
ByteArrayResource: TRepresents a byte array.

Resource API Example

The example below demonstrates the use of Resource interface. Let us have working Eclipse IDE in place and follow the following steps to create a Spring application:

Create a project: Create a project with a name SpringExternalResourceExample and create a package com.javabeat under the src directory in the created project.
Add Libraries: Add required Spring libraries using Add External JARs option as explained in the article Customizing callback methods.
Create source files: Create Java classe MainApp under the com.javabeat package.
Create configuration file: Create XML based configuration file Beans.xml under src directory.

Contents of MainApp.java are as below:

package com.javabeat;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.core.io.Resource;

public class MainApp {
	public static void main(String[] args) throws Exception {
		ApplicationContext ctx = new ClassPathXmlApplicationContext("Beans.xml");

		Resource resource = ctx.getResource("file:c:\\SampleResourceFile.txt");
		try {
			InputStream is = resource.getInputStream();
			BufferedReader br = new BufferedReader(new InputStreamReader(is));

			String line;
			while ((line = br.readLine()) != null) {
				System.out.println(line);
			}
			br.close();

		} catch (IOException e) {
			e.printStackTrace();
		}

	}

}

Note that we have used the getResource() to load a text file from File system. Suppose say you have the text file from URL path then the code would be as below:

Resource resource =  ctx.getResource("url:http://www.exampledomain.com/SampleResourceFile.txt");

If you want to load the the text file from the classpath then the line of code would be as below:

Resource resource = ctx.getResource("classpath:com/javabeat/SampleResourceFile.txt");

The contents of the Beans.xml are as below:

The SampleResourceFile.txt contains the following text:

**********************************
HI I'M AN EXTERNAL RESOURCE FILE
**********************************

This is a standalone application and does not need the Spring container. Now execute the above code then the output would be as below:

**********************************
HI I'M AN EXTERNAL RESOURCE FILE
**********************************

Injecting Resources

Now let’s say you want to have a reference of the resource which you may use in your application; this can be achieved in two ways:

Resource Injection: By using setter method.
Using ResourceLoader: Here we use ResourceLoader interface to help us get an instance of the resource we require. Such technique is used for loading dynamic resources i.e which will be loaded based on some business logic.

Example for Resource Injection

Setup the project as in the example above:
Contents of ProjectService.java are:

package com.javabeat;

import org.springframework.core.io.Resource;

public class ProductService {

	private Resource externalResource;

	public Resource getExternalResource() {
		return externalResource;
	}

	public void setExternalResource(Resource externalResource) {
		this.externalResource = externalResource;
	}
}

In the above class, I’ve created a property of type Resource.

Contents of MainApp.java are:

package com.javabeat;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.core.io.Resource;

public class MainApp {
	public static void main(String[] args) throws Exception {
		ApplicationContext ctx = new ClassPathXmlApplicationContext("Beans.xml");
		ProductService productService = (ProductService) ctx
				.getBean("productService");

		try {
			Resource resource = productService.getExternalResource();
			InputStream is = resource.getInputStream();
			BufferedReader br = new BufferedReader(new InputStreamReader(is));

			String line;
			while ((line = br.readLine()) != null) {
				System.out.println(line);
			}
			br.close();

		} catch (IOException e) {
			e.printStackTrace();
		}

	}

}

In the above test class, we get the bean in the usual way and when you get the externalResource property from this bean, you can successfully read the information from this resource object.
Contents of Beans.xml are:

In the above Beans.xml file I’ve have injected the property with the path of the file we want spring to provide us with.
Executing the above code gives the below output :

**********************************
HI I'M AN EXTERNAL RESOURCE FILE
**********************************

Example for ResourceLoader

Setup the project as in the example above:
Contents of ProjectService.java are:

package com.javabeat;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.core.io.Resource;
import org.springframework.core.io.ResourceLoader;

public class ProductService {

	@Autowired
	private ResourceLoader resourceLoader;

	public Resource getResource(String location) {
		return resourceLoader.getResource(location);
	}
}

The above class has a property type ResourceLoader. ResourceLoader is used to dynamically load the resource. To tell the spring about injecting value into this, we have used the @Autowired annotation. With annotations, we need not create setter methods for our properties. Only thing we have to do is to tell Spring framework that we are using the annotation, so in addition to the injecting values based on the property tags from the xml, it has to read class level annotations also. We do this by adding in the Beans.xml file.

Contents of MainApp.java are:

package com.javabeat;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.core.io.Resource;

public class MainApp {
	public static void main(String[] args) throws Exception {
		ApplicationContext ctx = new ClassPathXmlApplicationContext("Beans.xml");
		ProductService productService = (ProductService) ctx
				.getBean("productService");

		Resource resource = productService
				.getResource("file:c:\\SampleResourceFile.txt");
		try {
			InputStream is = resource.getInputStream();
			BufferedReader br = new BufferedReader(new InputStreamReader(is));

			String line;
			while ((line = br.readLine()) != null) {
				System.out.println(line);
			}
			br.close();

		} catch (IOException e) {
			e.printStackTrace();
		}

	}

}

Contents of Beans.xml are:

Executing the above code gives the below output :

**********************************
HI I'M AN EXTERNAL RESOURCE FILE
**********************************

Summary

In this post I discussed about the external resource injection in Spring applications. This is part-1 of the series, in the next post I shall cover another feature ResourceLoaderAware interface, Resources as dependencies and Application contexts and Resource paths. Please refer here for the official documentation on resource API. If you are interested in receiving the future articles, please subscribe here. follow us on @twitter and @facebook

New Features in Spring 3.1

Manisha Patil — Thu, 25 Apr 2013 14:31:07 +0000

Connect to us ( @twitter | @facebook )

This post will feature some of the major features and enhancements of Spring 3.1. Released in the year 2011, Spring 3.1 introduced many new exciting features as listed and described in this article. This article would provide very good idea on the new features introduced and how it is different from the previous versions. If you are developer who are interested in choosing the spring version, this article would be very useful.

also read: follow us on @twitter and @facebook

Cache Abstraction

Spring 3.1 has introduced a new feature called Cache Abstraction. Through this feature Spring can add caching concept to any existing application with very few changes in the code. Some of the features of Cache abstraction are:

Declarative caching for Spring applications, which means minimal impact on code and we can plug in various caching solutions to the existing applications.
This feature is not an implementation, but an abstraction.
This feature frees you from writing logic, but does not provide stores. Cache abstraction provides integration with two storage’s – one on top of the JDK ConcurrentMap and one for ehcache library.
Key annotations are @Cacheable and @CacheEvict.
You can use Spring EL for key and condition attributes
Annotations triggered by .

Environment Abstraction

Injectable environment abstraction API, org.springframework.core.env.Environment, has been integrated throughout the spring container. This has two core concepts:

Bean Profile
Property Source

These explained in the next sections. Spring’s Environment abstraction provides a single location to configure both profiles and properties.

Bean Definition Profiles

Bean definition profiles represent a general-purpose way that allows for registration of different beans in different environments. i.e it determines which bean definitions should be registered for a given deployment context. Some of the features of Bean Definition Profiles are:

As mentioned above , this feature helps logical grouping of bean definitions, for e.g., dev, staging, prod
Configuration of XML is done via . Java-based configuration is done via @Profile.
Activation of profiles can be done programmatically, using servlet init-params in web.xml, through system property, in tests via @ActiveProfiles.

PropertySource Abstraction

As mentioned above, Spring’s Environment abstraction provides search operations over a configurable hierarchy of property sources.
A PropertySource is a simple abstraction over any source of key-value pairs. E.g:property files, system properties,
servlet context, JNDI, etc.

Spring’s DefaultEnvironment is configured with two PropertySource objects

one representing the set of JVM system properties (System.getProperties())
one representing the set of system environment variables (System.getenv())

Code equivalents for Spring’s XML namespaces

Spring XML namespace elements like , and , have code-based equivalents since Spring 3.1 most in the form of @Enable annotations. These work in conjunction with the Spring’s @Configuration classes.

@Enable Annotations:

Applied at the class-level on @Configuration classes
Roughly equivalent to their XML namespace counterparts
Annotations available in Spring 3.1 are: @EnableTransactionManagement, @EnableAsync, @EnableScheduling, @EnableLoadTimeWeaving, @EnableWebMvc, @EnableCaching, @EnableAspectJAutoProxy, @EnableLoadTimeWeaving, @EnableSpringConfigured

Support for Hibernate 4.x

Spring 3.1, support Hibernate 4.x, natively and through JPA. Native support is through a dedicated org.springframework.orm.hibernate4 package, dealing with package rearrangements in the Hibernate API. It also presers the compatibility with Hibernate 3.2.

TestContext framework support for @Configuration classes and bean definition profiles

@Configuration (JavaConfig) annotation has been added in Spring 3.0. TestContext framework (located in the org.springframework.test.context package) provides annotation-driven testing support. Spring 3.1 adds loader attribute to @ContextConfiguration for @Configuration.

c: namespace for more concise constructor injection

c: Namespace for XML Configuration, is a shortcut for . It allows usage of inline argument values. It is analogous to existing “p:” namespace.

Support for injection against non-standard JavaBeans setters

Spring 3.1 now supports injection against non-standard JavaBeans setters, useful with method-chaining, where setter methods return a reference to ‘this’. In earlier Spring versions, for Spring to inject against a property method, the method had to conform strictly to JavaBeans property rules, namely that the setter method must return void.

Support for Servlet 3 code-based configuration of Servlet Container

Spring 3.1 supports Servlet 3. It provides :

Explicit support for Servlet 3.0 containers like Tomcat 7 and GlassFish 3 while preserving compatibility with Servlet 2.4+.
Support for XML-free web application setup (no web.xml) i.e Servlet 3.0′s ServletContainerInitializer plus Spring 3.1′s AnnotationConfigWebApplicationContext plus the environment abstraction. This means that there’s no need for web.xml to boodstrap the Spring 3.1 application.
Exposure of native Servlet 3.0 functionality in Spring MVC, i.e support for asynchronous request processing and standard Servlet 3.0 file upload support behind Spring’s MultipartResolver abstraction.

JPA EntityManagerFactory bootstrapping without persistence.xml

With Spring 3.1, the JPA EntityManagerFactory can be bootstrapped without persistence.xml or other metadata files. Using the LocalContainerEntityManagerFactoryBean packagesToScan property, you can specify the base packages to scan for @Entity classes. This is similar to Spring’s component-scan feature for regular Spring beans.

New HandlerMethod-based Support Classes For Annotated Controller Processing

HandlerMethod is a proper abstraction for the selected “handler” in Spring MVC. HandlerMethod support classes are:

RequestMappingHandlerMapping
RequestMappingHandlerAdapter
ExceptionHandlerExceptionResolver

“consumes” and “produces” conditions in @RequestMapping

Since Spring 3.1 we can specify mediatype that is accepted and provided by mapped controller method. It is much more powerful than specifying Content-Type or Accept headers as used to do before.
Example:

@RequestMapping(method = POST, consumes ="application/json", produces="application/json")
@ResponseStatus(CREATED)
@ResponseBody

Flash Attributes and RedirectAttributes

Flash attributes provide a way for one request to store attributes intended for use in another, most commonly used when using redirects like the Post/Redirect/Get pattern. Flash attributes are stored in FlashMap and stored in HTTP sessions, making it available to the request after the redirect and then removed immediately.

URI Template Variable Enhancements

URI template variables are now used in addition to request parameters when binding a request to @ModelAttribute arguments. @PathVariable method argument values are also merged into the model before rendering. A redirect string can contain placeholders for URI variables, and a @ModelAttribute method argument can be instantiated from a URI template variable as long as there is a registered Converter or PropertyEditor.

@Valid On @RequestBody Controller Method Arguments

Request body can be validated using Bean Validation API. An @RequestBody method argument can be annotated with @Valid to invoke automatic validation as seen in the example below:

@RequestMapping(method = POST, consumes = "application/json")
@ResponseStatus(CREATED)
@ResponseBody
public Task create(@Valid @RequestBody Task task) {
// No BindingResult in method signature
}

@RequestPart Annotation On Controller Method Arguments

The @RequestPart annotation can be used to associate a multipart/form-data request part with a method argument. It allows you to have the content of a specific multipart passed through an HttpMessageConverter, taking into consideration the multipart content-type.

UriComponentsBuilder and UriComponents

UriComponents : class is an immutable container of URI components providing access to all contained URI components.
UriComponentsBuilder: class help create UriComponents instances.

Together the above two classes give fine-grained control over all aspects of preparing a URI including construction, expansion from URI template variables, and encoding.

Summary

In this post I highlighted all the new features of Spring 3.1 though not in details. For further details you can refer the official documentation of Spring. If you are interested in receiving the future articles, please subscribe here. follow us on @twitter and @facebook.

@Inject and @Named (JSR 330) Annotations Example

Manisha Patil — Thu, 25 Apr 2013 14:06:47 +0000

Connect to us ( @twitter | @facebook )

Support for JSR-330 annotations was introduced in Spring 3. These annotations are scanned the same way as the Spring annotations, only requirement would be to have the relevant jars in your classpath. You can use the following annotations in Spring 3 applications:

@Inject instead of Spring’s @Autowired to inject a bean.
@Named instead of Spring’s @Component to declare a component/bean.(@Component can be referred from my previous post Classpath Scaning)

also read: follow us on @twitter and @facebook

@Inject and @Named Annotations Example

Let’s tweak the same example I used in my previous post on Classpath Scanning and managed Components and use the annotations @Inject and @Named. Let us have working Eclipse IDE in place and follow the following steps to create a Spring application:

Create a project: Create a project with a name SpringAnnotationExamples and create a package com.javabeat.injectandnamedannotations under the src directory in the created project.
Add Libraries: Add required Spring libraries using Add External JARs option as explained in the article Customizing callback methods.
Create source files: Create Java classes Product, ProductDao, ProductDaoImpl, ProductService and MainApp under the com.javabeat.injectandnamedannotations package.
Create configuration file: Create XML based configuration file Beans.xml under src directory.

Contents of Product.java are:

 package com.javabeat.injectandnamedannotations;

 public class Product {
 	String name;

 	public Product(String name) {
 		super();
 		this.name = name;
 	}

 	public String getName() {
 		return "Product name is:" + name;
 	}

 	public void setName(String name) {
 		this.name = name;
 	}
 }

Contents of ProductDao.java are:

 package com.javabeat.injectandnamedannotations;

 public interface ProductDao {
 	public Product getProduct(String id);
 }

Contents of ProductDaoImpl.java are:

  package com.javabeat.injectandnamedannotations;

  import java.util.HashMap;
  import java.util.Map;

  import javax.inject.Named;

  import org.springframework.context.annotation.Scope;
  import org.springframework.stereotype.Repository;

  @Named
  public class ProductDaoImpl implements ProductDao {
  	private Map products;

  	public ProductDaoImpl() {
  		products = new HashMap();
  		products.put("P1", new Product("Product1"));
  		products.put("P2", new Product("Product2"));
  		products.put("P3", new Product("Product3"));

  	}

  	public Product getProduct(String id) {
  		return products.get(id);
  	}

  }

Contents of ProductService.java are:

  package com.javabeat.injectandnamedannotations;

  import javax.inject.Inject;
  import javax.inject.Named;

  import org.springframework.beans.factory.annotation.Autowired;
  import org.springframework.stereotype.Service;

  @Named
  public class ProductService {
  	@Inject
  	private ProductDao productDao;

  	public Product getProductDetail(String productId) {
  		Product product = productDao.getProduct(productId);
  		return product;
  	}
  }

Contents of Beans.xml are:

The Contents of MainApp are:

package com.javabeat.injectandnamedannotations;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class MainApp {
	public static void main(String[] args) {

		ApplicationContext context = new ClassPathXmlApplicationContext(
				new String[] {"Beans.xml" });

		ProductService productService = (ProductService) context
				.getBean("productService");
		System.out.println(productService.getProductDetail("P1").getName());
		System.out.println(productService.getProductDetail("P2").getName());
		System.out.println(productService.getProductDetail("P3").getName());

	}
}

Execute the code
The final step is run the application. Once all the above code is ready execute and the below output appears on the console:

 Product name is:Product1
 Product name is:Product2
 Product name is:Product3

One of the limitations while using @Inject is, it has no required attribute.

Summary

In this article I demonstrated with an example the use of JSR-330 annotations- @Inject and @Named. If you are interested in receiving the future articles, please subscribe here. follow us on @twitter and @facebook

Spring Classpath Scanning & Managed Components

Manisha Patil — Tue, 23 Apr 2013 13:48:46 +0000

Connect to us ( @twitter | @facebook )

In my previous articles I have explained about the some of the popular annotations in Spring @Required, @Autowired and @Qualifier. You could note from these posts that we declared all the beans or components in XML bean configuration file; this helps Spring container detect and register beans or components. In this post I shall discuss about another feature of Spring i.e.Component Scanning. This means Spring is able to auto scan, detect and instantiate beans from pre-defined project package, hence saving us from tedious beans/component declaration in XML file.

also read: follow us on @twitter and @facebook

Stereotype Annotations

The basic annotation denoting a Spring-managed component is @Component (Denotes a auto scan component.). Other more particular stereotypes include

@Repository: Denotes DAO component in the persistence layer.
@Service: Denotes a Service component in the business layer.
@Controller: Denotes a controller component in the presentation layer.

If you look at the source code for each of these components (org.springframework.stereotype.Repository, org.springframework.stereotype.Service, org.springframework.stereotype.Controller), they internally use the @Component annotation. Though you can use only @Component annotation throughout your code, this would not be considered as a good practise. Hence using @Repository, @Service, @Controller annotations helps us seperate the persistence, business and presentation layers.

Example for Auto Scan Components

The following example demonstrates the use of all the above annotations mentioned. Let us have working Eclipse IDE in place and follow the following steps to create a Spring application:

Create a project: Create a project with a name SpringClassPathScanningExample and create a package com.javabeat under the src directory in the created project.
Add Libraries: Add required Spring libraries using Add External JARs option as explained in the article Customizing callback methods.
Create source files: Create Java classes Product, interface ProductDao, implementation ProductDaoImpl, ProductService and MainApp under the com.javabeat package.
Create configuration file: Create XML based configuration file bean.xml under src directory.

Contents of Product.java are:

 package com.javabeat;

 public class Product {
 	String name;

 	public Product(String name) {
 		super();
 		this.name = name;
 	}

 	public String getName() {
 		return "Product name is:" + name;
 	}

 	public void setName(String name) {
 		this.name = name;
 	}
 }

This class contains only name field and its respective getter and setter methods.

ProductDao is an interface for the Data Access Object (DAO), which is responsible for accessing data from the database. This has a single method getProduct(), which Product object from the table by its ID. Contents of ProductDao.java are:

 package com.javabeat;

 public interface ProductDao {
 	public Product getProduct(String id);
 }

In a production application, we need to implement this DAO interface using a data-access technology such as JDBC or object/relational mapping. But for testing purposes, let’s use maps to store the Product instances as shown below. Contents of ProductDaoImpl.java are:

  package com.javabeat;

  import java.util.HashMap;
  import java.util.Map;

  import org.springframework.stereotype.Component;

  @Component
  public class ProductDaoImpl implements ProductDao {
  	private Map products;

  	public ProductDaoImpl() {
  		products = new HashMap();
  		products.put("P1", new Product("Product1"));
  		products.put("P2", new Product("Product2"));
  		products.put("P3", new Product("Product3"));

  	}

  	public Product getProduct(String id) {
  		return products.get(id);
  	}

  }

The component scanning feature as explained above, can automatically scan, detect, and instantiate your components from the classpath. By default, Spring can detect all components with a stereotype annotation. We can apply basic annotation @Component to ProductDaoImpl class as shown above.

We also need a service object, acting as a facade, to provide the sequence generation service. Internally, this service object will interact with the DAO to handle the Product generation requests. So it requires a reference to the DAO as in the service class below. Contents of ProductService.java are:

 package com.javabeat;

 import org.springframework.beans.factory.annotation.Autowired;
 import org.springframework.stereotype.Component;

 @Component
 public class ProductService {
 	@Autowired
 	private ProductDao productDao;

 	public Product getProductDetail(String productId) {
 		Product product = productDao.getProduct(productId);
 		return product;
 	}
 }

We will also apply @Component stereotype annotation to the ProductService class for Spring to detect it. In addition, we have applied the @Autowired annotation to the DAO field for Spring to auto-wire it by type. Note that because we’re using the annotation on a field, you don’t need a setter method here.

Now that we have applied the stereotype annotations to our component classes, we ask Spring to scan them by declaring a single XML element: . In this element, you need to specify the package for scanning your components (You can use commas to separate multiple packages for scanning.). Then the specified package and all its sub packages will be scanned. Spring will give the bean a name created by lower casing the first character of the class and using the rest of the camel-cased name for the bean name. In our case the base package name is com.javabeat. Contents of bean.xml are:

Contents of MainApp are as below:

 package com.javabeat;

 import org.springframework.context.ApplicationContext;
 import org.springframework.context.support.ClassPathXmlApplicationContext;

 public class MainApp {
 	public static void main(String[] args) {

 		ApplicationContext context = new ClassPathXmlApplicationContext(
 				new String[] { "bean.xml" });

 		ProductService productService = (ProductService) context.getBean("productService");
 		System.out.println(productService.getProductDetail("P1").getName());
 		System.out.println(productService.getProductDetail("P2").getName());
 		System.out.println(productService.getProductDetail("P3").getName());

 	}
 }

Here you can note the statement:

 ProductService productService = (ProductService) context.getBean("productService");

This element will also register an AutowiredAnnotationBeanPostProcessor instance that can auto-wire properties with the @Autowired annotation.

Execute the code

The final step is run the application. Once all the above code is ready execute and the below output appears on the console:

Product name is:Product1
Product name is:Product2
Product name is:Product3

As mentioned in section Stereotype Annotations, @Component is a basic stereotype for denoting components of general purposes. The other types @Repository and @Service annotations can be used for our above example as shown below, without affecting its functionality and result. @Repository stereotype denotes a DAO component in the persistence layer, hence we will apply it to our ProductDaoImpl as shown below:

package com.javabeat;

import java.util.HashMap;
import java.util.Map;

import org.springframework.stereotype.Repository;

@Repository
public class ProductDaoImpl implements ProductDao {
	private Map products;

	public ProductDaoImpl() {
		products = new HashMap();
		products.put("P1", new Product("Product1"));
		products.put("P2", new Product("Product2"));
		products.put("P3", new Product("Product3"));

	}

	public Product getProduct(String id) {
		return products.get(id);
	}

}

@Service stereotype denotes a service component in the service layer. Hence it can be applied as below:

package com.javabeat;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class ProductService {
	@Autowired
	private ProductDao productDao;

	public Product getProductDetail(String productId) {
		Product product = productDao.getProduct(productId);
		return product;
	}
}

Filtering Components to Scan

By default, Spring will detect all classes annotated with @Component, @Repository, @Service, @Controller,or your custom annotation type that is itself annotated with @Component. You can customize the scan by applying one or more include/exclude filters.

Spring supports five types of filter expressions.

annotation: You can specify an annotation type for filtering.
assignable: You can specify a class/interface for filtering.
aspectj: Allow you to specify an AspectJ pointcut expression for matching the classes.
regex: Allows you to specify a regular expression for matching the classes.
custom: A custom implementation of the org.springframework.core.type .TypeFilter interface.

You can disable the default filters with the use-default-filters attribute.
For example, the following component scan includes all classes whose name contains the word Dao or Service, and excludes the classes with the @Controller annotation:

Because you have applied include filters to detect all classes whose name contains the word Dao or Service, the ProductDaoImpl and ProductService components can be auto-detected even without a stereotype annotation.

Naming Detected Components

By default, Spring will name the detected components by lowercasing the first character of the nonqualified class name. For example, the ProductService class will be named as productService. You can define the name for a component explicitly by specifying it in the stereotype annotation’s value as shown below:

package com.javabeat;
.......
import org.springframework.stereotype.Service;

@Service("productService")
public class ProductService {
	@Autowired
	private ProductDao productDao;
.........
.........
}
}

}

package com.javabeat;

..........
import org.springframework.stereotype.Repository;

@Repository("productDao")
public class ProductDaoImpl implements ProductDao {
	........
	........

}

We can develop our own naming strategy by implementing the BeanNameGenerator interface and specifying it in the name-generator attribute of the element.

Spring Aspect Oriented Programming (AOP)

Providing Scope for Auto detected Components

By default most common scope for auto detected components is singleton. However, sometimes you need other scopes, which Spring 2.5 provides with a new @Scope annotation. We simply need to provide the name of the scope within the annotation as shown below:

package com.javabeat;

.......
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Repository;

@Scope("prototype")
@Repository("productDao")
public class ProductDaoImpl implements ProductDao {
	private Map products;
......
.....
	}
}

Summary

In this post we saw how Spring auto detects the components from classpath, hence relieving us of the hassles of XML configurations.
By default, it can detect all components with particular stereotype annotations. But you can further include or exclude your components with filters. You can also provide scopes for the auto detected components. Component scanning is a powerful feature that can reduce the amount of configurations. If you are interested in receiving the future articles, please subscribe here. also read: follow us on @twitter and @facebook

@Resource, @PostConstruct and @PreDestroy Annotations Example

Manisha Patil — Sun, 21 Apr 2013 11:30:22 +0000

Connect to us ( @twitter | @facebook )

In this post I shall cover the JSR250 annotations. Introduced in Spring 2.5, it added support for JSR-250 based annotations which include @Resource, @PostConstruct and @PreDestroy annotations. In my previous articles I have explained about the some of the popular annotations in Spring @Required, @Autowired and @Qualifier. Also please read about How to write Custom Spring Callback Methods?

also read: follow us on @twitter and @facebook

@Resource vs @Autowired

@Resource is similar to @Autowired in functionality. @Autowired is Spring’s Annotation(only usable in Spring) whereas @Resource is JSR-250 Common Annotation equivalent (works the same in Java EE 5). Though the functionality for the two annotations being same, @Autowired is the only annotation that you can put on constructors.

By default auto wiring is done by object type. If you have two beans of the same type, then there is ambiguity that Spring can’t figure out which of the two beans to inject. That is when @Qualifier is used. It helps fix the ambiguity and tell Spring which of the two beans to inject. Use @Qualifier with @Autowired. With @Resource you can just put the bean name in the annotation as an attribute.

@PostConstruct and @PreDestroy

These annotations are alternative methods for defining initialization and destruction callback functions which I covered in post Customizing callback methods.

Example using @Resource, @PostConstruct and @PreDestroy

The example in post, demostrates the use of @Resource, @PostConstruct and @PreDestroy annotations.

Let us have working Eclipse IDE in place and follow the following steps to create a Spring application:

Create a project: Create a project with a name SpringAnnotationExamples and create a package com.javabeat.jsrannotations under the src directory in the created project.
Add Libraries: Add required Spring libraries using Add External JARs option as explained in the article Customizing callback methods.
Create source files: Create Java classes Product,Type and MainApp under the com.javabeat.jsrannotations package.
Create configuration file: Create XML based configuration file BeansJSRAnnotation.xml under src directory.

The class Product.java, is simple POJO class having name,price and an object of Type class. Contents of Product.java are:

 package com.javabeat.jsrannotations;

 import javax.annotation.PostConstruct;
 import javax.annotation.PreDestroy;
 import javax.annotation.Resource;

 public class Product {
 	private Integer price;
 	private String name;

 	@Resource(name = "typeB")
 	private Type type;

 	public Integer getPrice() {
 		return price;
 	}

 	public void setPrice(Integer price) {
 		this.price = price;
 	}

 	public Type getType() {
 		return type;
 	}

 	public String getName() {
 		return name;
 	}

 	public void setName(String name) {
 		this.name = name;
 	}

 	@PostConstruct
 	public void init() {
 		System.out.println("In init block of Product");
 	}

 	@PreDestroy
 	public void destroy() {
 		System.out.println("In destroy block of Product");
 	}
}

Here you note that we have used @Resource annotation. @PostConstruct and @PreDestroy are used for their respective lifecycle callback methods. Here you can see, I’ve used the @Qualifier annotation alongwith the @Autowired annotation.

The Type.java class is also a POJO class having a string object called “type”. Contents of Type.java are:

 package com.javabeat.jsrannotations;

 public class Type {

  	private String productType;

 	public String getProductType() {
 		return productType;
 	}

 	public void setProductType(String productType) {
 		this.productType = productType;
 	}

 }

Contents of MainApp are:

 package com.javabeat.jsrannotations;

 import org.springframework.context.support.AbstractApplicationContext;
 import org.springframework.context.support.ClassPathXmlApplicationContext;

 public class MainApp {
 	public static void main(String[] args) {
 		AbstractApplicationContext context = new ClassPathXmlApplicationContext(
 				"BeansJSRAnnotation.xml");

 		Product product = (Product) context.getBean("product");

 		System.out.println("Product Name : " + product.getName());
 		System.out.println("Price : " + product.getPrice());

 		Type productType = product.getType();

 		System.out.println(product.getName() + " is of type:"
 				+ productType.getProductType());
 		context.registerShutdownHook();
 	}
}

Here you need to register a shutdown hook registerShutdownHook() method that is declared on the AbstractApplicationContext class. This will ensures a graceful shutdown and calls the relevant destroy methods.

Contents of BeansJSRAnnotation.xml are:

As you can note here we are having two beans of same type.In Product.java I’ve used @Resource(“typeB”) it means we want to autowire Type property of Product with bean id=”typeB” in XML configuration file. You can also note that init-method and destroy-method attribute are used to specify the name of the method that has a return void, no argument method signature (init() and destroy method respectively from Product.java).

Spring Aspect Oriented Programming (AOP)

Execute the code

The final step is run the application. Once all the above code is ready execute and the below output appears on the console:

In init block of Product
Product Name : ProductA
Price : 400
ProductA is of type:Import
In destroy block of Product

Summary

In this post I discussed with and example about the use of JSR250 annotations. In the next article I shall cover the JSR330 annotations(@Inject and @Named). If you are interested in receiving the future articles, please subscribe here. follow us on @twitter and @facebook.

@Qualifier Annotation in Spring

Manisha Patil — Sat, 20 Apr 2013 12:33:26 +0000

Connect to us ( @twitter | @facebook )

In this post I shall cover another annotation @Qualifier which helps fine-tune annotation-based autowiring. In the previous post we saw how we could use @Autowired annotation on setter methods, fields and constructors. There may be scenarios when we create more than one bean of the same type and want to wire only one of them with a property. This can be controlled using @Qualifier annotation along with the @Autowired annotation.

also read: follow us on @twitter and @facebook

@Qualifier Example

Let us have working Eclipse IDE in place and follow the following steps to create a Spring application:

Create a project: Create a project with a name SpringAnnotationExamples and create a package com.javabeat.qualifierexample under the src directory in the created project.
Add Libraries: Add required Spring libraries using Add External JARs option as explained in the article Customizing callback methods.
Create source files: Create Java classes Product,Type and MainApp under the com.javabeat.qualifierexample package.
Create configuration file: Create XML based configuration file BeansQualifierAnnotation.xml under src directory.

The class Product.java, is simple POJO class having name,price and an object of Type class. Contents of Product.java are:

 package com.javabeat.qualifierexample;

 import org.springframework.beans.factory.annotation.Autowired;
 import org.springframework.beans.factory.annotation.Qualifier;

 public class Product {
 	private Integer price;
 	private String name;

 	@Autowired
 	@Qualifier("typeB")
 	private Type type;

 	public Integer getPrice() {
 		return price;
 	}

 	public void setPrice(Integer price) {
 		this.price = price;
 	}

 	public Type getType() {
 		return type;
 	}

 	public String getName() {
 		return name;
 	}

 	public void setName(String name) {
 		this.name = name;
 	}
 }

Here you can see, I’ve used the @Qualifier annotation alongwith the @Autowired annotation.

The Type.java class is also a POJO class having a string object called “type”. Contents of Type.java are:

 package com.javabeat.autowireexample;

 public class Type {

 	private String type;

 	public String getType() {
 		return type;
 	}

 	public void setType(String type) {
 		this.type = type;
 	}
 }

Contents of MainApp are:

 package com.javabeat.qualifierexample;

 import org.springframework.context.ApplicationContext;
 import org.springframework.context.support.ClassPathXmlApplicationContext;

 public class MainApp {
 	public static void main(String[] args) {
 	      ApplicationContext context =
 	             new ClassPathXmlApplicationContext("BeansQualifierAnnotation.xml");

 	      Product product = (Product) context.getBean("product");

 	      System.out.println("Product Name : " + product.getName() );
 	      System.out.println("Price : " + product.getPrice() );

 	      Type productType = product.getType();

 	      System.out.println(product.getName()+" is of type:" + productType.getType() );
 	   }
 }

Contents of BeansQualifierAnnotation.xml are:

As you can note here we are having two beans of same type. In Product.java I’ve used @Qualifier(“typeB”) it means we want to autowire Type property of Product with bean id=”typeB” in XML configuration file.

Spring Aspect Oriented Programming (AOP)

Execute the code
The final step is run the application. Once all the above code is ready execute and the below output appears on the console:

Product Name : ProductA
Price : 400
ProductA is of type:Import

Summary

In this post we saw how to configure the Spring container using the @Qualifier annotation. This annotation can be used for on setter methods, on fields, on constructors, with arguments. Examples for the same has been demonstrated. In the next article I shall discuss about JSR-250 Annotations. If you are interested in receiving the future articles, please subscribe here. follow us on @twitter and @facebook.