Create a Java Config with @Configuration and @Bean to Create POJOs

To define instances of a POJO class in the Spring IoC container, you can create a Java config class with instantiation values. A Java config class with a POJO or bean definition looks like this:

package com.apress.springrecipes.sequence.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import com.apress.springrecipes.sequence.SequenceGenerator;

@Configuration
public class SequenceGeneratorConfiguration {

    @Bean
    public SequenceGenerator sequenceGenerator() {
        SequenceGenerator seqgen = new SequenceGenerator();
        seqgen.setPrefix("30");
        seqgen.setSuffix("A");
        seqgen.setInitial("100000");
        return seqgen;
    }
}

Notice the SequenceGeneratorConfiguration class is decorated with the @Configuration annotation; this tells Spring it’s a configuration class. When Spring encounters a class with the @Configuration annotation, it looks for bean instance definitions in the class, which are Java methods decorated with the @Bean annotation. The Java methods create and return a bean instance.

Any method definitions decorated with the @Bean annotation generates a bean name based on the method name. Alternatively, you can explicitly specify the bean name in the @Bean annotation with the name attribute. For example, @Bean(name="mys1") makes the bean available as mys1.

Instantiate the Spring IoC Container to Scan for Annotations

You have to instantiate the Spring IoC container to scan for Java classes that contain annotations. In doing so, Spring detects @Configuration and @Bean annotations so you can later get bean instances from the IoC container itself.

Spring provides two types of IoC container implementations. The basic one is called a bean factory. The more advanced one is called an application context, which is compatible with the bean factory. Note the configuration files for these two types of IoC containers are identical.

The application context provides more advanced features than the bean factory while keeping the basic features compatible. Therefore, we strongly recommend using the application context for every application unless the resources of an application are restricted (e.g., such as when running Spring for an applet or a mobile device). The interfaces for the bean factory and the application context are BeanFactory and ApplicationContext, respectively. The ApplicationContext interface is a subinterface of BeanFactory for maintaining compatibility.

Since ApplicationContext is an interface, you have to instantiate an implementation of it. Spring has several application context implementations; we recommend you use AnnotationConfigApplicationContext, which is the newest and most flexible implementation. With this class you can load the Java config file.

ApplicationContext context = new AnnotationConfigApplicationContext    (SequenceGeneratorConfiguration.class);

Once the application context is instantiated, the object reference—in this case context—provides an entry point to access the POJO instances or beans.

Get POJO Instances or Beans from the IoC Container

To get a declared bean from a bean factory or an application context, you just make a call to the getBean() method and pass in the unique bean name. The return type of the getBean() method is java.lang.Object, so you have to cast it to its actual type before using it.

SequenceGenerator generator =
    (SequenceGenerator) context.getBean("sequenceGenerator");

The getBean() method also supports another variation where you can provide the bean class name to avoid making the cast.

SequenceGenerator generator = context.getBean("sequenceGenerator",SequenceGenerator.class);

If there is only a single bean, you can omit the bean name.

SequenceGenerator generator = context.getBean(SequenceGenerator.class);

Once you reach this step, you can use the POJO or bean just like any object created using a constructor outside of Spring.

A Main class to run the sequence generator application would look like the following:

package com.apress.springrecipes.sequence;

import com.apress.springrecipes.sequence.config.SequenceGeneratorConfiguration;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Main {

    public static void main(String[] args) {
        ApplicationContext context =
            new AnnotationConfigApplicationContext(SequenceGeneratorConfiguration.class);

        SequenceGenerator generator = context.getBean(SequenceGenerator.class);

        System.out.println(generator.getSequence());
        System.out.println(generator.getSequence());
    }
}

If everything is available in the Java classpath (the SequenceGenerator POJO class and the Spring JAR dependencies), you should see the following output, along with some logging messages:

30100000A
30100001A

Create POJO Class with the @Component Annotation to Create Beans with DAO

Up to this point, the Spring bean instantiations have been done by hard-coding the values in a Java config class. This was the preferred approach to simplify the Spring examples.

However, the POJO instantiation process for most applications is done from either a database or user input. So, now it’s time to move forward and use a more real-world scenario. For this section, we’ll use a Domain class and a Data Access Object (DAO) class to create POJOs. You still won’t need to set up a database—you’ll actually hard-code values in the DAO class—but familiarizing yourself with this type of application structure is important since it’s the basis for most real-world applications and future recipes.

Suppose you are asked to develop a sequence generator application like the one you did in the previous section. You’ll need to modify the class structure slightly to accommodate a Domain class and DAO pattern. First, create a domain class called Sequence containing the id, prefix, and suffix properties.

package com.apress.springrecipes.sequence;

public class Sequence {

    private final String id;
    private final String prefix;
    private final String suffix;

    public Sequence(String id, String prefix, String suffix) {
        this.id = id;
        this.prefix = prefix;
        this.suffix = suffix;
    }

    public String getId() {
        return id;
    }

    public String getPrefix() {
        return prefix;
    }

    public String getSuffix() {
        return suffix;
    }

}

Then, you create an interface for the DAO, which is responsible for accessing data from the database. The getSequence() method loads a POJO or Sequence object from a database table by its ID, while the getNextValue() method retrieves the next value of a particular database sequence.

package com.apress.springrecipes.sequence;

public interface SequenceDao {

    public Sequence getSequence(String sequenceId);
    public int getNextValue(String sequenceId);
}

In a production application, you would implement this DAO interface to use a data-access technology. But to simplify this example, you’ll implement a DAO with hard-coded values in a Map to store the sequence instances and values.

package com.apress.springrecipes.sequence;

import org.springframework.stereotype.Component;

import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.atomic.AtomicInteger;

@Component("sequenceDao")
public class SequenceDaoImpl implements SequenceDao {

    private final Map<String, Sequence> sequences = new HashMap<>();
    private final Map<String, AtomicInteger> values = new HashMap<>();

    public SequenceDaoImpl() {
        sequences.put("IT", new Sequence("IT", "30", "A"));
        values.put("IT", new AtomicInteger(10000));
    }

    public Sequence getSequence(String sequenceId) {
        return sequences.get(sequenceId);
    }

    public int getNextValue(String sequenceId) {
        AtomicInteger value = values.get(sequenceId);
        return value.getAndIncrement();
    }
}

Observe how the SequenceDaoImpl class is decorated with the @Component("sequenceDao") annotation. This marks the class so Spring can create POJOs from it. The value inside the @Component annotation defines the bean instance ID, in this case sequenceDao. If no bean value name is provided in the @Component annotation, by default the bean name is assigned as the uncapitalized nonqualified class name. For example, for the SequenceDaoImpl class, the default bean name would be sequenceDaoImpl.

A call to the getSequence method returns the value of the given sequenceID. And a call to the getNextValue method creates a new value based on the value of the given sequenceID and returns the new value.

POJOs are classified in application layers. In Spring there are three layers: persistence, service, and presentation. @Component is a general-purpose annotation to decorate POJOs for Spring detection, whereas @Repository, @Service, and @Controller are specializations of @Component for more specific cases of POJOs associated with the persistence, service, and presentation layers.

If you’re unsure about a POJO’s purpose, you can decorate it with the @Component annotation. However, it’s better to use the specialization annotations where possible because these provide extra facilities based on a POJO’s purpose (e.g., @Repository causes exceptions to be wrapped up as DataAccessExceptions, which makes debugging easier).

Instantiate the Spring IoC Container with Filters to Scan for Annotations

By default, Spring detects all classes decorated with @Configuration, @Bean, @Component, @Repository, @Service, and @Controller annotations, among others. You can customize the scan process to include one or more include/exclude filters. This is helpful when a Java package has dozens or hundreds of classes. For certain Spring application contexts, it can be necessary to exclude or include POJOs with certain annotations.

Spring supports four types of filter expressions. The annotation and assignable types are to specify an annotation type and a class/interface for filtering. The regex and aspectj types allow you to specify a regular expression and an AspectJ pointcut expression for matching the classes. You can also disable the default filters with the use-default-filters attribute.

For example, the following component scan includes all classes in com.apress.springrecipes.sequence whose name contains the word Dao or Service and excludes the classes with the @Controller annotation:

@ComponentScan(
    includeFilters = {
        @ComponentScan.Filter(
            type = FilterType.REGEX,
            pattern = {"com.apress.springrecipes.sequence.*Dao", "com.apress.springrecipes.sequence.*Service"})
    },
    excludeFilters = {
        @ComponentScan.Filter(
            type = FilterType.ANNOTATION,
            classes = {org.springframework.stereotype.Controller.class}) }
        )

When applying include filters to detect all classes whose name contains the word Dao or Service, even classes that don’t have annotations are autodetected.

Get POJO Instances or Beans from the IoC Container

Then, you can test the preceding components with the following Main class :

package com.apress.springrecipes.sequence;

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Main {

    public static void main(String[] args) {

        ApplicationContext context =
            new AnnotationConfigApplicationContext("com.apress.springrecipes.sequence");

        SequenceDao sequenceDao = context.getBean(SequenceDao.class);

        System.out.println(sequenceDao.getNextValue("IT"));
        System.out.println(sequenceDao.getNextValue("IT"));
    }
}                                                                                                              

Create the POJO Classes with Constructors

Then you create two product subclasses, Battery and Disc. Each of them has its own properties.

package com.apress.springrecipes.shop;

public class Battery extends Product {

    private boolean rechargeable;

    public Battery() {
        super();
    }

    public Battery(String name, double price) {
        super(name, price);
    }

    // Getters and Setters                
    ...
}

package com.apress.springrecipes.shop;

public class Disc extends Product {

    private int capacity;

    public Disc() {
        super();
    }

    public Disc(String name, double price) {
        super(name, price);
    }

    // Getters and Setters                
    ...
}

Create a Java Config for Your POJO

To define instances of a POJO class in the Spring IoC container, you have to create a Java config class with instantiation values. A Java config class with a POJO or bean definition made by invoking constructors would look like this:

package com.apress.springrecipes.shop.config;

import com.apress.springrecipes.shop.Battery;
import com.apress.springrecipes.shop.Disc;
import com.apress.springrecipes.shop.Product;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class ShopConfiguration {

    @Bean
    public Product aaa() {
        Battery p1 = new Battery("AAA", 2.5);
        p1.setRechargeable(true);
        return p1;
    }

    @Bean
    public Product cdrw() {
        Disc p2 = new Disc("CD-RW", 1.5);
        p2.setCapacity(700);
        return p2;
    }
}

Next, you can write the following Main class to test your products by retrieving them from the Spring IoC container:

package com.apress.springrecipes.shop;

import com.apress.springrecipes.shop.config.ShopConfiguration;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Main {

    public static void main(String[] args) throws Exception {

        ApplicationContext context =
            new AnnotationConfigApplicationContext(ShopConfiguration.class);

        Product aaa = context.getBean("aaa", Product.class);
        Product cdrw = context.getBean("cdrw", Product.class);
        System.out.println(aaa);
        System.out.println(cdrw);
    }
}                                                                                      

Reference POJOs in a Java Config Class

When POJO instances are defined in a Java config class—as illustrated in recipe 2-1 and recipe 2-2—POJO references are straightforward to use because everything is Java code. In the following example, a bean property references another bean:

package com.apress.springrecipes.sequence.config;

import com.apress.springrecipes.sequence.DatePrefixGenerator;
import com.apress.springrecipes.sequence.SequenceGenerator;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class SequenceConfiguration {

    @Bean
    public DatePrefixGenerator datePrefixGenerator() {
        DatePrefixGenerator dpg = new DatePrefixGenerator();
        dpg.setPattern("yyyyMMdd");
        return dpg;
    }

    @Bean
    public SequenceGenerator sequenceGenerator() {
        SequenceGenerator sequence = new SequenceGenerator();
        sequence.setInitial(100000);
        sequence.setSuffix("A");
        sequence.setPrefixGenerator(datePrefixGenerator());
        return sequence;
    }
}

The prefixGenerator property of the SequenceGenerator class is an instance of a DatePrefixGenerator bean.

The first bean declaration creates a DatePrefixGenerator POJO. By convention, the bean becomes accessible with the bean name datePrefixGenerator (i.e., the method name). But since the bean instantiation logic is also a standard Java method , the bean is also accessible by making a standard Java call. When the prefixGenerator property is set—in the second bean, via a setter—a standard Java call is made to the method datePrefixGenerator() to reference the bean.

Autowire POJO Fields with the @Autowired Annotation

Next, let’s use autowiring on the SequenceDao field of the DAO SequenceDaoImpl class introduced in the second part of recipe 2-1. You’ll add a service class to the application to illustrate autowiring with the DAO class.

A service class to generate service objects is another real-world application best practice, which acts as a façade to access DAOs—instead of accessing DAOs directly. Internally, the service object interacts with the DAO to handle the sequence generation requests.

package com.apress.springrecipes.sequence;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
public class SequenceService {

    @Autowired
    private SequenceDao sequenceDao;

    public void setSequenceDao(SequenceDao sequenceDao) {
        this.sequenceDao = sequenceDao;
    }

    public String generate(String sequenceId) {
        Sequence sequence = sequenceDao.getSequence(sequenceId);
        int value = sequenceDao.getNextValue(sequenceId);
        return sequence.getPrefix() + value + sequence.getSuffix();
    }
}

The SequenceService class is decorated with the @Component annotation. This allows Spring to detect the POJO. Because the @Component annotation has no name, the default bean name is sequenceService, which is based on the class name.

The sequenceDao property of the SequenceService class is decorated with the @Autowired annotation. This allows Spring to autowire the property with the sequenceDao bean (i.e., the SequenceDaoImpl class).

The @Autowired annotation can also be applied to a property of an array type to have Spring autowire all the matching beans. For example, you can annotate a PrefixGenerator[] property with @Autowired. Then, Spring will autowire all the beans whose type is compatible with PrefixGenerator at one time.

package com.apress.springrecipes.sequence;

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

public class SequenceGenerator {

    @Autowired
    private PrefixGenerator[] prefixGenerators;
    ...
}

If you have multiple beans whose type is compatible with the PrefixGenerator defined in the IoC container, they will be added to the prefixGenerators array automatically.

In a similar way, you can apply the @Autowired annotation to a type-safe collection. Spring can read the type information of this collection and autowire all the beans whose type is compatible.

package com.apress.springrecipes.sequence;

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

public class SequenceGenerator {

    @Autowired
    private List<PrefixGenerator> prefixGenerators;
    ...
}

If Spring notices that the @Autowired annotation is applied to a type-safe java.util.Map with strings as the keys, it will add all the beans of the compatible type, with the bean names as the keys, to this map.

package com.apress.springrecipes.sequence;

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

public class SequenceGenerator {

    @Autowired
    private Map<String, PrefixGenerator> prefixGenerators;
    ...
}

Autowire POJO Methods and Constructors with the @Autowired Annotation and Make Autowiring Optional

The @Autowired annotation can also be applied directly to the setter method of a POJO. As an example, you can annotate the setter method of the prefixGenerator property with @Autowired. Then, Spring attempts to wire a bean whose type is compatible with prefixGenerator.

package com.apress.springrecipes.sequence;

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

public class SequenceGenerator {
    ...
    @Autowired
    public void setPrefixGenerator(PrefixGenerator prefixGenerator) {
        this.prefixGenerator = prefixGenerator;
    }
}

By default, all the properties with @Autowired are required. When Spring can’t find a matching bean to wire, it will throw an exception. If you want a certain property to be optional, set the required attribute of @Autowired to false. Then, when Spring can’t find a matching bean, it will leave this property unset.

package com.apress.springrecipes.sequence;

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

public class SequenceGenerator {
    ...
    @Autowired(required=false)
    public void setPrefixGenerator(PrefixGenerator prefixGenerator) {
        this.prefixGenerator = prefixGenerator;
    }
}

You may also apply the @Autowired annotation to a method with an arbitrary name and an arbitrary number of arguments; in that case, Spring attempts to wire a bean with the compatible type for each of the method arguments.

package com.apress.springrecipes.sequence;

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

public class SequenceGenerator {
    ...
    @Autowired
    public void myOwnCustomInjectionName(PrefixGenerator prefixGenerator) {
        this.prefixGenerator = prefixGenerator;
    }
}

Finally, you may also apply the @Autowired annotation to a constructor that you want to be used for autowiring. The constructor can have any number of arguments, and Spring will attempt to wire a bean with the compatible type for each of the constructor arguments.

@Service
public class SequenceService {

    private final SequenceDao sequenceDao;

    @Autowired
    public SequenceService(SequenceDao sequenceDao) {
        this.sequenceDao=sequenceDao;
    }

    public String generate(String sequenceId) {
        Sequence sequence = sequenceDao.getSequence(sequenceId);
        int value = sequenceDao.getNextValue(sequenceId);
        return sequence.getPrefix() + value + sequence.getSuffix();
    }
}

Resolve Autowire Ambiguity with Annotations

By default, autowiring by type will not work when there is more than one bean with the compatible type in the IoC container and the property isn’t a group type (e.g., array, list, map), as illustrated previously. However, there are two workarounds to autowiring by type if there’s more than one bean of the same type: the @Primary annotation and the @Qualifier annotation.

package com.apress.springrecipes.sequence;
...
import org.springframework.stereotype.Component;
import org.springframework.context.annotation.Primary;

@Component
@Primary
public class DatePrefixGenerator implements PrefixGenerator {

    public String getPrefix() {
        DateFormat formatter = new SimpleDateFormat("yyyyMMdd");
        return formatter.format(new Date());
    }
}

package com.apress.springrecipes.sequence;

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

public class SequenceGenerator {

    @Autowired
    @Qualifier("datePrefixGenerator")
    private PrefixGenerator prefixGenerator;
    ...
}

package com.apress.springrecipes.sequence;

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

public class SequenceGenerator {
    ...
    @Autowired
    public void myOwnCustomInjectionName(
        @Qualifier("datePrefixGenerator") PrefixGenerator prefixGenerator) {
        this.prefixGenerator = prefixGenerator;
    }
}

Resolve POJO References from Multiple Locations

As an application grows, it can become difficult to manage every POJO in a single Java configuration class. A common practice is to separate POJOs into multiple Java configuration classes according to their functionalities. When you create multiple Java configuration classes, obtaining references and autowiring POJOs that are defined in different classes isn’t as straightforward as when everything is in a single Java configuration class.

One approach is to initialize the application context with the location of each Java configuration class. In this manner, the POJOs for each Java configuration class are loaded into the context and references, and autowiring between POJOs is possible.

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext    (PrefixConfiguration.class, SequenceGeneratorConfiguration.class);

Another alternative is to use the @Import annotation so Spring makes the POJOs from one configuration file available in another.

package com.apress.springrecipes.sequence.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Import;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Configuration;
import com.apress.springrecipes.sequence.SequenceGenerator;
import com.apress.springrecipes.sequence.PrefixGenerator;

@Configuration
@Import(PrefixConfiguration.class)
public class SequenceConfiguration {
    @Value("#{datePrefixGenerator}")
    private PrefixGenerator prefixGenerator;

    @Bean
    public SequenceGenerator sequenceGenerator() {
        SequenceGenerator sequence= new SequenceGenerator();
        sequence.setInitial(100000);
        sequence.setSuffix("A");
        sequence.setPrefixGenerator(prefixGenerator);
        return sequence;
    }
}

The sequenceGenerator bean requires you to set a prefixGenerator bean. But notice no prefixGenerator bean is defined in the Java configuration class. The prefixGenerator bean is defined in a separate Java configuration class called PrefixConfiguration. With the @Import(PrefixConfiguration.class) annotation, Spring brings all the POJOs in the Java configuration class into the scope of the present configuration class. With the POJOs from PrefixConfiguration in scope, you use the @Value annotation and SpEL to inject the bean named datePrefixGenerator into the prefixGenerator field. Once the bean is injected, it can be used to set a prefixGenerator bean for the sequenceGenerator bean.

Autowire POJOs with the @Resource Annotation

By default, the @Resource annotation works like Spring’s @Autowired annotation and attempts to autowire by type. For example, the following POJO attribute is decorated with the @Resource annotation, so Spring attempts to locate a POJO that matches the PrefixGenerator type.

package com.apress.springrecipes.sequence;

import javax.annotation.Resource;

public class SequenceGenerator {

    @Resource
    private PrefixGenerator prefixGenerator;
    ...
}

However, unlike the @Autowired annotation, which requires the @Qualifier annotation to autowire a POJO by name, the @Resource ambiguity is eliminated if more than one POJO type of the same kind exists. Essentially, the @Resource annotation provides the same functionality as putting together the @Autowired annotation and the @Qualifier annotation.

Autowire POJOs with the @Inject Annotation

Also, the @Inject annotation attempts to autowire by type, like the @Resource and @Autowired annotations. For example, the following POJO attribute is decorated with the @Inject annotation, so Spring attempts to locate a POJO that matches the PrefixGenerator type:

package com.apress.springrecipes.sequence;

import javax.inject.Inject;

public class SequenceGenerator {

    @Inject
    private PrefixGenerator prefixGenerator;
    ...
}

But just like the @Resource and @Autowired annotations, a different approach has to be used to match POJOs by name or avoid ambiguity if more than one POJO type of the same kind exists. The first step to do autowiring by name with the @Inject annotation is to create a custom annotation to identify both the POJO injection class and the POJO injection point.

package com.apress.springrecipes.sequence;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

import javax.inject.Qualifier;

@Qualifier
@Target({ElementType.TYPE, ElementType.FIELD, ElementType.PARAMETER})
@Documented
@Retention(RetentionPolicy.RUNTIME)
public @interface DatePrefixAnnotation {
}

Notice the custom annotation makes use of the @Qualifier annotation. This annotation is different from the one used with Spring’s @Qualifier annotation, as this last class belongs to the same Java package as the @Inject annotation (i.e., javax.inject).

Once the custom annotation is done, it’s necessary to decorate the POJO injection class that generates the bean instance, which in this case is the DatePrefixGenerator class.

package com.apress.springrecipes.sequence;
...
@DatePrefixAnnotation
public class DatePrefixGenerator implements PrefixGenerator {
...
}

Finally, the POJO attribute or injection point is decorated with the same custom annotation to qualify the POJO and eliminate any ambiguity.

package com.apress.springrecipes.sequence;

import javax.inject.Inject;

public class SequenceGenerator {

    @Inject @DataPrefixAnnotation
    private PrefixGenerator prefixGenerator;
    ...
}

As you’ve seen in recipes 2-3 and 2-4, the three annotations @Autowired, @Resource, and @Inject can achieve the same result. The @Autowired annotation is a Spring-based solution, whereas the @Resource and @Inject annotations are Java standard (i.e., JSR) solutions. If you’re going to do name-based autowiring, the @Resource annotation offers the simplest syntax. For autowiring by class type, all three annotations are straightforward to use because all three require a single annotation.

Use Properties File Data to Set Up POJO Instantiation Values

Let’s assume you have a series of values in a properties file you want to access to set up bean properties. Typically this can be the configuration properties of a database or some other application values composed of key values. For example, take the following key values stored in a file called discounts.properties:

specialcustomer.discount=0.1 summer.discount=0.15 endofyear.discount=0.2

package com.apress.springrecipes.shop.config;

import com.apress.springrecipes.shop.Battery;
import com.apress.springrecipes.shop.Disc;
import com.apress.springrecipes.shop.Product;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.PropertySource;
import org.springframework.context.support.PropertySourcesPlaceholderConfigurer;

@Configuration
@PropertySource("classpath:discounts.properties")
@ComponentScan("com.apress.springrecipes.shop")
public class ShopConfiguration {

    @Value("${endofyear.discount:0}")
    private double specialEndofyearDiscountField;

    @Bean
    public static PropertySourcesPlaceholderConfigurer        propertySourcesPlaceholderConfigurer() {
        return new PropertySourcesPlaceholderConfigurer();
    }
                                                                  
    @Bean
    public Product dvdrw() {
        Disc p2 = new Disc("DVD-RW", 3.0, specialEndofyearDiscountField);
        p2.setCapacity(700);
        return p2;
    }
}

You define a @PropertySource annotation with a value of classpath:discounts.properties to decorate the Java config class. The classpath: prefix tells Spring to look for the discounts.properties file in the Java classpath.

Once you define the @PropertySource annotation to load the properties file, you also need to define a PropertySourcePlaceholderConfigurer bean with the @Bean annotation. Spring automatically wires the @PropertySource discounts.properties file so its properties become accessible as bean properties.

Next, you need to define Java variables to take values from the discount discounts.properties file. To define the Java variable values with these values, you make use of the @Value annotation with a placeholder expression.

The syntax is @Value("${key:default_value}"). A search is done for the key value in all the loaded application properties. If a matching key=value is found in the properties file, the corresponding value is assigned to the bean property. If no matching key=value is found in the loaded application properties, default_value (i.e., after ${key:) is assigned to the bean property.

Once a Java variable is set with a discount value, you can use it to set up bean instances for a bean’s discount property.

If you want to use properties file data for a different purpose than setting up bean properties, you should use Spring’s Resource mechanism, which is described next.

Use Data from Any External Resource File for Use in a POJO

Suppose you want to display a banner on application startup. The banner consists of the following characters and stored in a text file called banner.txt. This file can be put in the classpath of your application.

*************************
*  Welcome to My Shop!  *
*************************

Next, let’s write a BannerLoader POJO class to load the banner and output it to the console.

package com.apress.springrecipes.shop;
import org.springframework.core.io.Resource;
...
import javax.annotation.PostConstruct;
public class BannerLoader {

    private Resource banner;

    public void setBanner(Resource banner) {
        this.banner = banner;
    }

    @PostConstruct
    public void showBanner() throws IOException {
        InputStream in = banner.getInputStream();

        BufferedReader reader = new BufferedReader(new InputStreamReader(in));
        while (true) {
            String line = reader.readLine();
            if (line == null)
                break;
            System.out.println(line);
        }
        reader.close();
    }
}

Notice the POJO banner field is a Spring Resource type. The field value will be populated through setter injection when the bean instance is created—to be explained shortly. The showBanner() method makes a call to the getInputStream() method to retrieve the input stream from the Resource field. Once you have an InputStream, you’re able to use a standard Java file manipulation class. In this case, the file contents are read line by line with BufferedReader and output to the console.

Also notice the showBanner() method is decorated with the @PostConstruct annotation. Because you want to show the banner at startup, you use this annotation to tell Spring to invoke the method automatically after creation. This guarantees the showBanner() method is one of the first methods to be run by the application and therefore ensures the banner appears at the outset.

Next, the POJO BannerLoader needs to be initialized as an instance. In addition, the banner field of the BannerLoader also needs to be injected. So, let’s create a Java config class for these tasks.

@Configuration
@PropertySource("classpath:discounts.properties")
@ComponentScan("com.apress.springrecipes.shop")
public class ShopConfiguration {

    @Value("classpath:banner.txt")
    private Resource banner;

    @Bean
    public static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer() {
        return new PropertySourcesPlaceholderConfigurer();
    }

    @Bean
    public BannerLoader bannerLoader() {
        BannerLoader bl = new BannerLoader();
        bl.setBanner(banner);
        return bl;
    }
}

See how the banner property is decorated with the @Value("classpath:banner.txt") annotation. This tells Spring to search for the banner.txt file in the classpath and inject it. Spring uses the preregistered property editor ResourceEditor to convert the file definition into a Resource object before injecting it into the bean.

Once the banner property is injected, it’s assigned to the BannerLoader bean instance via setter injection.

Because the banner file is located in the Java classpath, the resource path starts with the classpath: prefix. The previous resource path specifies a resource in the relative path of the file system. You can specify an absolute path as well.

file:c:/shop/banner.txt

When a resource is located in Java’s classpath , you have to use the classpath prefix. If there’s no path information presented, it will be loaded from the root of the classpath.

classpath:banner.txt

If the resource is located in a particular package, you can specify the absolute path from the classpath root.

classpath:com/apress/springrecipes/shop/banner.txt

Besides support to load from a file system path or the classpath, a resource can also be loaded by specifying a URL.

http://springrecipes.apress.com/shop/banner.txt

Since the bean class uses the @PostConstruct annotation on the showBanner() method, the banner is sent to output when the IoC container is set up. Because of this, there’s no need to tinker with an application’s context or explicitly call the bean to output the banner. However, sometimes it can be necessary to access an external resource to interact with an application’s context. Now suppose you want to display a legend at the end of an application. The legend consists of the discounts previously described in the discounts.properties file. To access the contents of the properties file, you can also leverage Spring’s Resource mechanism.

Next, let’s use Spring’s Resource mechanism, but this time directly inside an application’s Main class to output a legend when the application finishes.

import org.springframework.core.io.ClassPathResource;
import org.springframework.core.io.support.PropertiesLoaderUtils;
...
...
public class Main {

    public static void main(String[] args) throws Exception {
        ...
        Resource resource = new ClassPathResource("discounts.properties");
        Properties props = PropertiesLoaderUtils.loadProperties(resource);
        System.out.println("And don't forget our discounts!");
        System.out.println(props);

    }
}

Spring’s ClassPathResource class is used to access the discounts.properties file, which casts the file’s contents into a Resource object. Next, the Resource object is processed into a Properties object with Spring’s PropertiesLoaderUtils class. Finally, the contents of the Properties object are sent to the console as the final output of the application.

Because the legend file (i.e., discounts.properties) is located in the Java classpath, the resource is accessed with Spring’s ClassPathResource class. If the external resource were in a file system path, the resource would be loaded with Spring’s FileSystemResource.

Resource resource = new FileSystemResource("c:/shop/banner.txt")

If the external resource were at a URL, the resource would be loaded with Spring’s UrlResource.

Resource resource = new UrlResource("http://www.apress.com/")

Define Methods to Run Before POJO Initialization and Destruction with @PostConstruct and @PreDestroy

Another alterative if you’re defining POJO instances outside a Java config class (e.g., with the @Component annotation) is to use the @PostConstruct and @PreDestroy annotations directly in the POJO class.

@Component
public class Cashier {

    @Value("checkout")
    private String fileName;
    @Value("c:/Windows/Temp/cashier")
    private String path;
    private BufferedWriter writer;

    public void setFileName(String fileName) {
        this.fileName = fileName;
    }

    public void setPath(String path) {
        this.path = path;
    }

    @PostConstruct
    public void openFile() throws IOException {
        File targetDir = new File(path);
        if (!targetDir.exists()) {
            targetDir.mkdir();
        }
        File checkoutFile = new File(path, fileName + ".txt");
        if(!checkoutFile.exists()) {
            checkoutFile.createNewFile();
        }
        writer = new BufferedWriter(new OutputStreamWriter(
                 new FileOutputStream(checkoutFile, true)));
    }

    public void checkout(ShoppingCart cart) throws IOException {
        writer.write(new Date() + "	" +cart.getItems() + "
");
        writer.flush();
    }

    @PreDestroy
    public void closeFile() throws IOException {
        writer.close();
    }
}

The @ Component annotation tells Spring to manage the POJO, just like it’s been used in previous recipes. Two of the POJO fields’ values are set with the @Value annotation, a concept that was also explored in a previous recipe. The openFile() method is decorated with the @PostConstruct annotation, which tells Spring to execute the method right after a bean is constructed. The closeFile() method is decorated with the @PreDestroy annotation, which tells Spring to execute the method right before a bean is destroyed.

Define Lazy Initialization for POJOs with @Lazy

By default, Spring performs eager initialization on all POJOs. This means POJOs are initialized at startup. In certain circumstances, though, it can be convenient to delay the POJO initialization process until a bean is required. Delaying the initialization is called lazy initialization.

Lazy initialization helps limit resource consumption peaks at startup and save overall system resources. Lazy initialization can be particularly relevant for POJOs that perform heavyweight operations (e.g., network connections, file operations). To mark a bean with lazy initialization, you decorate a bean with the @Lazy annotation.

package com.apress.springrecipes.shop;
...
import org.springframework.stereotype.Component;
import org.springframework.context.annotation.Scope;
import org.springframework.context.annotation.Lazy;

@Component
@Scope("prototype")
@Lazy
public class ShoppingCart {

    private List<Product> items = new ArrayList<>();

    public void addItem(Product item) {
        items.add(item);
    }

    public List<Product> getItems() {
        return items;
    }
}

In the previous declaration, because the POJO is decorated with the @Lazy annotation, if the POJO is never required by the application or referenced by another POJO, it’s never instantiated.

Define Initialization of POJOs Before Other POJOs with @DependsOn

As an application’s POJOs grow, so does the number of POJO initializations. This can create race conditions if POJOs reference one another and are spread out in different Java configuration classes. What happens if bean C requires the logic in bean B and bean F? If bean C is detected first and Spring hasn’t initialized bean B and bean F, you’ll get an error that can be hard to detect. To ensure that certain POJOs are initialized before other POJOs and to get a more descriptive error in case of a failed initialization process, Spring offers the @DependsOn annotation. The @DependsOn annotation ensures a given bean is initialized before another bean.

package com.apress.springrecipes.sequence.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.DependsOn;
import org.springframework.context.annotation.Configuration;
import com.apress.springrecipes.sequence.DatePrefixGenerator;
import com.apress.springrecipes.sequence.NumberPrefixGenerator;
import com.apress.springrecipes.sequence.SequenceGenerator;

@Configuration
public class SequenceConfiguration {
    @Bean
    @DependsOn("datePrefixGenerator")
    public SequenceGenerator sequenceGenerator() {
        SequenceGenerator sequence= new SequenceGenerator();
        sequence.setInitial(100000);
         sequence.setSuffix("A");
         return sequence;
    }
}

In the previous snippet, the declaration @DependsOn("datePrefixGenerator") ensures the datePrefixGenerator bean is created before the sequenceGenerator bean. The @DependsOn attribute also supports defining multiple dependency beans with a CSV list surrounded by {} (e.g., @DependsOn({"datePrefixGenerator,numberPrefixGenerator,randomPrefixGenerator"})

Create POJO to Process Every Bean Instance

To write a bean post-processor, a class has to implement BeanPostProcessor. When Spring detects a bean that implements this class, it applies the postProcessBeforeInitialization() and postProcessAfterInitialization() methods to all bean instances managed by Spring. You can implement any logic you want in these methods to either inspect, modify, or verify the status of a bean.

package com.apress.springrecipes.shop;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanPostProcessor;

import org.springframework.stereotype.Component;

@Component
public class AuditCheckBeanPostProcessor implements BeanPostProcessor {

    public Object postProcessBeforeInitialization(Object bean, String beanName)
        throws BeansException {
            System.out.println("In AuditCheckBeanPostProcessor.postProcessBeforeInitialization, processing bean type: " + bean.getClass());
        return bean;
    }

    public Object postProcessAfterInitialization(Object bean, String beanName)
        throws BeansException {
        return bean;
    }
}

Notice the postProcessBeforeInitialization() and postProcessAfterInitialization() methods must return the original bean instance even if you don’t do anything in the method.

To register a bean post-processor in an application context, just annotate the class with the @Component annotation. The application context is able to detect which bean implements the BeanPostProcessor interface and register it to process all other bean instances in the container.

Create a POJO to Process Selected Bean Instances

During bean construction, the Spring IoC container passes all the bean instances to the bean post-processor one by one. This means if you want to apply a bean post-processor to only certain types of beans, you must filter the beans by checking their instance type. This allows you to apply logic more selectively across beans.

Suppose you now want to apply a bean post-processor but just to Product bean instances. The following example is another bean post-processor that does this:

package com.apress.springrecipes.shop;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanPostProcessor;

import org.springframework.stereotype.Component;

@Component
public class ProductCheckBeanPostProcessor implements BeanPostProcessor {

    public Object postProcessBeforeInitialization(Object bean, String beanName)
        throws BeansException {
        if (bean instanceof Product) {
            String productName = ((Product) bean).getName();
                System.out.println("In ProductCheckBeanPostProcessor.postProcessBeforeInitialization, processing Product: " + productName);
        }
        return bean;
    }

    public Object postProcessAfterInitialization(Object bean, String beanName)
        throws BeansException {
        if (bean instanceof Product) {
            String productName = ((Product) bean).getName();
                System.out.println("In ProductCheckBeanPostProcessor.postProcessAfterInitialization, processing Product: " + productName);
        }
        return bean;
    }
}

Both the postProcessBeforeInitialization() and postProcessAfterInitialization() methods must return an instance of the bean being processed. However, this also means you can even replace the original bean instance with a new instance in your bean post-processor.

Verify POJO Properties with the @Required Annotation

In certain cases, it may be necessary to check whether particular properties have been set. Instead of creating of custom post-constructor to verify the particular properties of a bean, it’s possible to decorate a property with the @Required annotation. The @Required annotation provides access to the RequiredAnnotationBeanPostProcessor class—a Spring bean post-processor that can check whether certain bean properties have been set. Note that this processor can check only whether the properties have been set but can’t check whether their value is null or something else.

Suppose that both the prefixGenerator and suffix properties are required for a sequence generator. You can annotate their setter methods with @Required.

package com.apress.springrecipes.sequence;

import org.springframework.beans.factory.annotation.Required;

public class SequenceGenerator {

    private PrefixGenerator prefixGenerator;
    private String suffix;
    ...
    @Required
    public void setPrefixGenerator(PrefixGenerator prefixGenerator) {
        this.prefixGenerator = prefixGenerator;
    }

    @Required
    public void setSuffix(String suffix) {
        this.suffix = suffix;
    }
    ...
}

To ask Spring to check whether these properties have been set, you just need to enable scanning so Spring can detect and enforce the @Required annotation. If any properties with @Required have not been set, a BeanInitializationException error is thrown.

Create POJOs by Invoking a Static Factory Method

For example, you can write the following createProduct static factory method to create a product from a predefined product ID. According to the product ID, this method decides which concrete product class to instantiate. If there is no product matching this ID, it throws an IllegalArgumentException.

package com.apress.springrecipes.shop;

public class ProductCreator {

    public static Product createProduct(String productId) {
        if ("aaa".equals(productId)) {
            return new Battery("AAA", 2.5);
        } else if ("cdrw".equals(productId)) {
            return new Disc("CD-RW", 1.5);
        } else if ("dvdrw".equals(productId)) {
            return new Disc("DVD-RW", 3.0);
        }
        throw new IllegalArgumentException("Unknown product");
    }
}

To create a POJO with a static factory method inside an @Bean definition of a Java configuration class, you use regular Java syntax to call the factory method.

package com.apress.springrecipes.shop.config;

import com.apress.springrecipes.shop.Product;
import com.apress.springrecipes.shop.ProductCreator;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class ShopConfiguration {
    @Bean
    public Product aaa() {
        return ProductCreator.createProduct("aaa");
    }

    @Bean
    public Product cdrw() {
        return ProductCreator.createProduct("cdrw");
    }

    @Bean
    public Product dvdrw() {
        return ProductCreator.createProduct("dvdrw");
    }
}                                                                                      

Create POJOs by Invoking an Instance Factory Method

For example, you can write the following ProductCreator class by using a configurable map to store predefined products. The createProduct() instance factory method finds a product by looking up the supplied productId value in the map. If there is no product matching this ID, it will throw an IllegalArgumentException.

package com.apress.springrecipes.shop;
...
public class ProductCreator {

    private Map<String, Product> products;

    public void setProducts(Map<String, Product> products) {
        this.products = products;
    }

    public Product createProduct(String productId) {
        Product product = products.get(productId);
        if (product != null) {
            return product;
        }
        throw new IllegalArgumentException("Unknown product");
    }
}

To create products from this ProductCreator, you first declare an @Bean to instantiate the factory values. Next, you declare a second bean to act as a façade to access the factory. Finally, you can call the factory and execute the createProduct() method to instantiate other beans.

package com.apress.springrecipes.shop.config;

import com.apress.springrecipes.shop.Battery;
import com.apress.springrecipes.shop.Disc;
import com.apress.springrecipes.shop.Product;
import com.apress.springrecipes.shop.ProductCreator;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

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

@Configuration
public class ShopConfiguration {

    @Bean
    public ProductCreator productCreatorFactory() {

        ProductCreator factory = new ProductCreator();
        Map<String, Product> products = new HashMap<>();
        products.put("aaa", new Battery("AAA", 2.5));
        products.put("cdrw", new Disc("CD-RW", 1.5));
        products.put("dvdrw", new Disc("DVD-RW", 3.0));
        factory.setProducts(products);
        return factory;
    }
                                                                                          
    @Bean
    public Product aaa() {
        return productCreatorFactory().createProduct("aaa");
    }

    @Bean
    public Product cdrw() {
        return productCreatorFactory().createProduct("cdrw");
    }

    @Bean
    public Product dvdrw() {
        return productCreatorFactory().createProduct("dvdrw");
    }

}

Create POJOs Using Spring’s Factory Bean

Although you’ll seldom have to write custom factory beans, you may find it helpful to understand their internal mechanisms through an example. For example, you can write a factory bean for creating a product with a discount applied to the price. It accepts a product property and a discount property to apply the discount to the product and return it as a new bean.

package com.apress.springrecipes.shop;

import org.springframework.beans.factory.config.AbstractFactoryBean;

public class DiscountFactoryBean extends AbstractFactoryBean<Product> {

    private Product product;
    private double discount;

    public void setProduct(Product product) {
        this.product = product;
    }

    public void setDiscount(double discount) {
        this.discount = discount;
    }

    public Class<?> getObjectType() {
        return product.getClass();
    }

    protected Product createInstance() throws Exception {
        product.setPrice(product.getPrice() * (1 - discount));
        return product;
    }
}

By extending the AbstractFactoryBean class, the factory bean can simply override the createInstance() method to create the target bean instance. In addition, you have to return the target bean’s type in the getObjectType() method for the autowiring feature to work properly.

Next, you can declare product instances using a regular @Bean annotation to apply DiscountFactoryBean.

package com.apress.springrecipes.shop.config;

import com.apress.springrecipes.shop.Battery;
import com.apress.springrecipes.shop.Disc;
import com.apress.springrecipes.shop.DiscountFactoryBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

@Configuration
@ComponentScan("com.apress.springrecipes.shop")
public class ShopConfiguration {
    @Bean
    public Battery aaa() {
        Battery aaa = new Battery("AAA", 2.5);
        return aaa;
    }

    @Bean
    public Disc cdrw() {
        Disc aaa = new Disc("CD-RW", 1.5);
        return aaa;
    }

    @Bean
    public Disc dvdrw() {
        Disc aaa = new Disc("DVD-RW", 3.0);
        return aaa;
    }
                                                                                          
    @Bean
    public DiscountFactoryBean discountFactoryBeanAAA() {
        DiscountFactoryBean factory = new DiscountFactoryBean();
        factory.setProduct(aaa());
        factory.setDiscount(0.2);
        return factory;
    }

    @Bean
    public DiscountFactoryBean discountFactoryBeanCDRW() {
        DiscountFactoryBean factory = new DiscountFactoryBean();
        factory.setProduct(cdrw());
        factory.setDiscount(0.1);
        return factory;
    }

    @Bean
    public DiscountFactoryBean discountFactoryBeanDVDRW() {
        DiscountFactoryBean factory = new DiscountFactoryBean();
        factory.setProduct(dvdrw());
        factory.setDiscount(0.1);
        return factory;
    }
}                                                                                      

Create a Java Configuration Class with the @Profile Annotation

Let’s create a multiple Java configuration class with an @Profile annotation for the shopping application presented in previous recipes.

package com.apress.springrecipes.shop.config;

import com.apress.springrecipes.shop.Cashier;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;

@Configuration
@Profile("global")
@ComponentScan("com.apress.springrecipes.shop")
public class ShopConfigurationGlobal {

    @Bean(initMethod = "openFile", destroyMethod = "closeFile")
    public Cashier cashier() {
        final String path = System.getProperty("java.io.tmpdir") + "cashier";
        Cashier c1 = new Cashier();
        c1.setFileName("checkout");
        c1.setPath(path);
        return c1;
    }
}
package com.apress.springrecipes.shop.config;

import com.apress.springrecipes.shop.Battery;
import com.apress.springrecipes.shop.Disc;
import com.apress.springrecipes.shop.Product;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;

@Configuration
@Profile({"summer", "winter"})
public class ShopConfigurationSumWin {
    @Bean
    public Product aaa() {
        Battery p1 = new Battery();
        p1.setName("AAA");
        p1.setPrice(2.0);
        p1.setRechargeable(true);
        return p1;
    }
                                                                                                                                                              
    @Bean
    public Product cdrw() {
        Disc p2 = new Disc("CD-RW", 1.0);
        p2.setCapacity(700);
        return p2;
    }

    @Bean
    public Product dvdrw() {
        Disc p2 = new Disc("DVD-RW", 2.5);
        p2.setCapacity(700);
        return p2;
    }
}

The @Profile annotation decorates the entire Java configuration class, so all the @Bean instances belong to the same profile. To assign an @Profile name, you just place the name inside "". Notice it’s also possible to assign multiple @Profile names using a comma-separated value (CSV) syntax surrounded by {} (e.g., {"summer","winter"}).

Load the Profile into Environment

To load the beans from a certain profile into an application, you need to activate a profile. You can load multiple profiles at a time, and it’s also possible to load profiles programmatically, through a Java runtime flag or even as an initialization parameter of a WAR file.

To load profiles programmatically (i.e., via the application context), you get the context environment from where you can load profiles via the setActiveProfiles() method.

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
context.getEnvironment().setActiveProfiles("global", "winter");
context.scan("com.apress.springrecipes.shop");
context.refresh();

It’s also possible to indicate which Spring profile to load via a Java runtime flag. In this manner, you can pass the following runtime flag to load all beans that belong to the global and winter profiles:

-Dspring.profiles.active=global,winter

Set a Default Profile

To avoid the possibility of errors because no profiles are loaded into an application, you can define default profiles. Default profiles are used only when Spring can’t detect any active profiles, which are defined programmatically, via a Java runtime flag, or with a web application initialization parameter.

To set up default profiles, you can also use any of the three methods to set up active profiles. Programmatically you use the method setDefaultProfiles() instead of setActiveProfiles(), and via a Java runtime flag or web application initialization parameter , you can use the spring.profiles.default parameter instead of spring.profiles.active.

Declare Aspects, Advices, and Pointcuts

An aspect is a Java class that modularizes a set of concerns (e.g., logging or transaction management) that cuts across multiple types and objects. Java classes that modularize such concerns are decorated with the @Aspect annotation. In AOP terminology, aspects are also complemented by advices, which in themselves have pointcuts. An advice is a simple Java method with one of the advice annotations. AspectJ supports five types of advice annotations : @Before, @After, @AfterReturning, @AfterThrowing, and @Around. A pointcut is an expression that looks for types and objects on which to apply the aspect’s advices.

Aspect with @Before Advice

To create a before advice to handle crosscutting concerns before particular program execution points, you use the @Before annotation and include the pointcut expression as the annotation value.

package com.apress.springrecipes.calculator;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class CalculatorLoggingAspect {

    private Log log = LogFactory.getLog(this.getClass());

    @Before("execution(* ArithmeticCalculator.add(..))")
    public void logBefore() {
        log.info("The method add() begins");
    }
}

This pointcut expression matches the add() method execution of the ArithmeticCalculator interface. The preceding wildcard in this expression matches any modifier (public, protected, and private) and any return type. The two dots in the argument list match any number of arguments.

For the previous aspect to work (i.e., output its message), you need to set up logging. Specifically, create a logback.xml file with configuration properties like the following.

<?xml version="1.0" encoding="UTF-8"?>                
<configuration>                    

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">                
        <layout class="ch.qos.logback.classic.PatternLayout">                
            <Pattern>%d [%15.15t] %-5p %30.30c - %m%n</Pattern>                
        </layout>                
    </appender>                

    <root level="INFO">                
        <appender-ref ref="STDOUT" />                
    </root>                

</configuration>                    

Next, you create a Spring configuration to scan all POJOs, including the POJO calculator implementation and aspect and including the @EnableAspectJAutoProxy annotation.

@Configuration
@EnableAspectJAutoProxy
@ComponentScan
public class CalculatorConfiguration {
}

As the last step, you can test the aspect with the following Main class:

package com.apress.springrecipes.calculator;

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Main {

    public static void main(String[] args) {

        ApplicationContext context =
            new AnnotationConfigApplicationContext(CalculatorConfiguration.class);

        ArithmeticCalculator arithmeticCalculator =
            context.getBean("arithmeticCalculator", ArithmeticCalculator.class);
        arithmeticCalculator.add(1, 2);
        arithmeticCalculator.sub(4, 3);
        arithmeticCalculator.mul(2, 3);
        arithmeticCalculator.div(4, 2);

        UnitCalculator unitCalculator = context.getBean("unitCalculator", UnitCalculator.class);
        unitCalculator.kilogramToPound(10);
        unitCalculator.kilometerToMile(5);
    }
}

The execution points matched by a pointcut are called join points. In this term, a pointcut is an expression to match a set of join points, while an advice is the action to take at a particular join point.

For your advice to access the detail of the current join point, you can declare an argument of type JoinPoint in your advice method. Then, you can get access to join point details such as the method name and argument values. Now, you can expand your pointcut to match all methods by changing the class name and method name to wildcards.

package com.apress.springrecipes.calculator;
...
import java.util.Arrays;

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Aspect
@Component
public class CalculatorLoggingAspect {
    ...
    @Before("execution(* *.*(..))")
    public void logBefore(JoinPoint joinPoint) {
        log.info("The method " + joinPoint.getSignature().getName()
            + "() begins with " + Arrays.toString(joinPoint.getArgs()));
    }
}

Use an Aspect with @After Advice

An after advice is executed after a join point finishes and is represented by a method annotated with @After, whenever it returns a result or throws an exception. The following after advice logs the calculator method ending:

package com.apress.springrecipes.calculator;
...
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class CalculatorLoggingAspect {
    ...
    @After("execution(* *.*(..))")
    public void logAfter(JoinPoint joinPoint) {
        log.info("The method " + joinPoint.getSignature().getName()
            + "() ends");
    }
}

Use an Aspect with @AfterReturning Advice

An after advice is executed regardless of whether a join point returns normally or throws an exception . If you would like to perform logging only when a join point returns, you should replace the after advice with an after returning advice.

package com.apress.springrecipes.calculator;
...
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.AfterReturning;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class CalculatorLoggingAspect {
    ...
    @AfterReturning("execution(* *.*(..))")
    public void logAfterReturning(JoinPoint joinPoint) {
        log.info("The method {}() ends with {}", joinPoint.getSignature().getName(), result);
    }
}

In an after returning advice, you can get access to the return value of a join point by adding a returning attribute to the @AfterReturning annotation. The value of this attribute should be the argument name of this advice method for the return value to pass in. Then, you have to add an argument to the advice method signature with this name. At runtime, Spring AOP will pass in the return value through this argument. Also note that the original pointcut expression needs to be presented in the pointcut attribute instead.

package com.apress.springrecipes.calculator;
...
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.AfterReturning;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class CalculatorLoggingAspect {
    ...
    @AfterReturning(
        pointcut = "execution(* *.*(..))",
        returning = "result")
    public void logAfterReturning(JoinPoint joinPoint, Object result) {
        log.info("The method " + joinPoint.getSignature().getName()
            + "() ends with " + result);
    }
}

Use an Aspect with @AfterThrowing Advice

An after throwing advice is executed only when an exception is thrown by a join point.

package com.apress.springrecipes.calculator;
...
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.AfterThrowing;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class CalculatorLoggingAspect {
    ...
    @AfterThrowing("execution(* *.*(..))")
    public void logAfterThrowing(JoinPoint joinPoint) {
        log.error("An exception has been thrown in {}()", joinPoint.getSignature().getName());
    }
}

Similarly, the exception thrown by the join point can be accessed by adding a throwing attribute to the @AfterThrowing annotation . The type Throwable is the superclass of all errors and exceptions in the Java language. So, the following advice will catch any of the errors and exceptions thrown by the join points:

package com.apress.springrecipes.calculator;
...
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.AfterThrowing;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class CalculatorLoggingAspect {
    ...
    @AfterThrowing(
        pointcut = "execution(* *.*(..))",
        throwing = "e")
    public void logAfterThrowing(JoinPoint joinPoint, Throwable e) {
        log.error("An exception {} has been thrown in {}()", e, joinPoint.getSignature().getName());
    }
}

However, if you are interested in one particular type of exception only, you can declare it as the argument type of the exception. Then your advice will be executed only when exceptions of compatible types (i.e., this type and its subtypes) are thrown.

package com.apress.springrecipes.calculator;
...
import java.util.Arrays;

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.AfterThrowing;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class CalculatorLoggingAspect {
    ...
    @AfterThrowing(
        pointcut = "execution(* *.*(..))",
        throwing = "e")
    public void logAfterThrowing(JoinPoint joinPoint, IllegalArgumentException e) {
        log.error("Illegal argument {} in {}()", Arrays.toString(joinPoint.getArgs()), joinPoint.getSignature().getName());
    }
}                                                                                                                                                      

Use an Aspect with @Around Advice

The last type of advice is an around advice . It is the most powerful of all the advice types. It gains full control of a join point, so you can combine all the actions of the preceding advices into one single advice. You can even control when, and whether, to proceed with the original join point execution.

The following around advice is the combination of the before, after returning, and after throwing advices you created earlier. Note that for an around advice, the argument type of the join point must be ProceedingJoinPoint. It’s a subinterface of JoinPoint that allows you to control when to proceed with the original join point.

package com.apress.springrecipes.calculator;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;

import java.util.Arrays;

@Aspect
@Component
public class CalculatorLoggingAspect {

    private Logger log = LoggerFactory.getLogger(this.getClass());

    @Around("execution(* *.*(..))")
    public Object logAround(ProceedingJoinPoint joinPoint) throws Throwable {

        log.info("The method {}() begins with {}", joinPoint.getSignature().getName(), Arrays.toString(joinPoint.getArgs()));
        try {
            Object result = joinPoint.proceed();
            log.info("The method {}() ends with ", joinPoint.getSignature().getName(), result);
            return result;
        } catch (IllegalArgumentException e) {
            log.error("Illegal argument {} in {}()", Arrays.toString(joinPoint.getArgs()) , joinPoint.getSignature().getName());
            throw e;
        }
    }
}

The around advice type is powerful and flexible in that you can even alter the original argument values and change the final return value. You must use this type of advice with great care, as the call to proceed with the original join point may easily be forgotten.

Use Method Signature Patterns

The most typical pointcut expressions are used to match a number of methods by their signatures . For example, the following pointcut expression matches all of the methods declared in the ArithmeticCalculator interface. The initial wildcard matches methods with any modifier (public, protected, and private) and any return type. The two dots in the argument list match any number of arguments.

execution(* com.apress.springrecipes.calculator.ArithmeticCalculator.*(..))

You can omit the package name if the target class or interface is located in the same package as the aspect.

execution(* ArithmeticCalculator.*(..))

The following pointcut expression matches all the public methods declared in the ArithmeticCalculator interface:

execution(public * ArithmeticCalculator.*(..))

You can also restrict the method return type. For example, the following pointcut matches the methods that return a double number:

execution(public double ArithmeticCalculator.*(..))

The argument list of the methods can also be restricted. For example, the following pointcut matches the methods whose first argument is of primitive double type. The two dots then match any number of followed arguments.

execution(public double ArithmeticCalculator.*(double, ..))

Or, you can specify all the argument types in the method signature for the pointcut to match.

execution(public double ArithmeticCalculator.*(double, double))

Although the AspectJ pointcut language is powerful in matching various join points, sometimes you may not be able to find any common characteristics (e.g., modifiers, return types, method name patterns, or arguments) for the methods you want to match. In such cases, you can consider providing a custom annotation for them. For instance, you can define the following marker annotation. This annotation can be applied to both method level and type level.

package com.apress.springrecipes.calculator;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target( { ElementType.METHOD, ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface LoggingRequired {
}

Next, you can annotate all methods that require logging with this annotation or the class itself to apply the behavior to all methods. Note that the annotations must be added to the implementation class but not the interface, as they will not be inherited.

package com.apress.springrecipes.calculator;

@LoggingRequired
public class ArithmeticCalculatorImpl implements ArithmeticCalculator {

    public double add(double a, double b) {
        ...
    }

    public double sub(double a, double b) {
        ...
    }

    ...
}

Then you can write a pointcut expression to match a class or methods with the @LoggingRequired annotation using the annotation keyword on the @Pointcut annotation.

package com.apress.springrecipes.calculator;

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class CalculatorPointcuts {

    @Pointcut("annotation(com.apress.springrecipes.calculator.LoggingRequired)")
    public void loggingOperation() {}

}                                                                                      

Use Type Signature Patterns

Another kind of pointcut expression matches all join points within certain types. When applied to Spring AOP, the scope of these pointcuts will be narrowed to matching all method executions within the types. For example, the following pointcut matches all the method execution join points within the com.apress.springrecipes.calculator package:

within(com.apress.springrecipes.calculator.*)

To match the join points within a package and its subpackage, you have to add one more dot before the wildcard.

within(com.apress.springrecipes.calculator..*)

The following pointcut expression matches the method execution join points within a particular class:

within(com.apress.springrecipes.calculator.ArithmeticCalculatorImpl)

Again, if the target class is located in the same package as this aspect, the package name can be omitted.

within(ArithmeticCalculatorImpl)

You can match the method execution join points within all classes that implement the ArithmeticCalculator interface by adding a plus symbol.

within(ArithmeticCalculator+)

The custom annotation @LoggingRequired can be applied to the class or method level, as illustrated previously.

package com.apress.springrecipes.calculator;

@LoggingRequired
public class ArithmeticCalculatorImpl implements ArithmeticCalculator {
    ...
}

Then you can match the join points within the classes or methods that have been annotated with @LoggingRequired using the within keyword on the @Pointcut annotation.

@Pointcut("within(com.apress.springrecipes.calculator.LoggingRequired)")
public void loggingOperation() {}

Combine Pointcut Expressions

In AspectJ, pointcut expressions can be combined with the operators && (and), || (or), and ! (not). For example, the following pointcut matches the join points within classes that implement either the ArithmeticCalculator or UnitCalculator interface:

within(ArithmeticCalculator+) || within(UnitCalculator+)

The operands of these operators can be any pointcut expressions or references to other pointcuts.

package com.apress.springrecipes.calculator;

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class CalculatorPointcuts {

    @Pointcut("within(ArithmeticCalculator+)")
    public void arithmeticOperation() {}

    @Pointcut("within(UnitCalculator+)")
    public void unitOperation() {}

    @Pointcut("arithmeticOperation() || unitOperation()")
    public void loggingOperation() {}
}

Declare Pointcut Parameters

One way to access join point information is by reflection (i.e., via an argument of type org.aspectj.lang.JoinPoint in the advice method). Besides, you can access join point information in a declarative way by using some kinds of special pointcut expressions . For example, the expressions target() and args() capture the target object and argument values of the current join point and expose them as pointcut parameters. These parameters are passed to your advice method via arguments of the same name.

package com.apress.springrecipes.calculator;
...
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Aspect
public class CalculatorLoggingAspect {
    ...
    @Before("execution(* *.*(..)) && target(target) && args(a,b)")
    public void logParameter(Object target, double a, double b) {
        log.info("Target class : {}", target.getClass().getName());
        log.info("Arguments : {}, {}", a,b);
    }
}

When declaring an independent pointcut that exposes parameters, you have to include them in the argument list of the pointcut method as well.

package com.apress.springrecipes.calculator;

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class CalculatorPointcuts {
    ...
    @Pointcut("execution(* *.*(..)) && target(target) && args(a,b)")
    public void parameterPointcut(Object target, double a, double b) {}
}

Any advice that refers to this parameterized pointcut can access the pointcut parameters via method arguments of the same name.

package com.apress.springrecipes.calculator;
...
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Aspect
public class CalculatorLoggingAspect {
    ...
    @Before("CalculatorPointcuts.parameterPointcut(target, a, b)")
    public void logParameter(Object target, double a, double b) {
        log.info("Target class : {}", target.getClass().getName());
        log.info("Arguments : {}, {}"a,b);
    }
}                                                                                      

Implement Load-Time Weaving with the AspectJ Weaver

AspectJ provides a load-time weaving agent to enable load-time weaving. You need only to add a VM argument to the command that runs your application. Then your classes will get woven when they are loaded into the JVM.

java -javaagent:lib/aspectjweaver-1.9.0.jar -jar Recipe_2_19_ii-4.0.0.jar

If you run your application with the preceding argument, you will get the following output and cache status. The AspectJ agent advises all calls to the Complex(int,int) constructor.

Cache MISS for (1,2)
Cache MISS for (2,3)
Cache MISS for (3,5)
(1 + 2i) + (2 + 3i) = (3 + 5i)
Cache MISS for (5,8)
Cache HIT for (2,3)
Cache HIT for (3,5)
(5 + 8i) - (2 + 3i) = (3 + 5i)

Implement Load-Time Weaving with Spring Load-Time Weaver

Spring has several load-time weavers for different runtime environments. To turn on a suitable load-time weaver for your Spring application, you need only to add @EnableLoadTimeWeaving to your configuration class.

Spring will be able to detect the most suitable load-time weaver for your runtime environment. Some Java EE application servers have class loaders that support the Spring load-time weaver mechanism, so there’s no need to specify a Java agent in their startup commands.

However, for a simple Java application , you still require a weaving agent provided by Spring to enable load-time weaving. You have to specify the Spring agent in the VM argument of the startup command.

java -javaagent:lib/spring-instrument-5.0.0.jar -jar Recipe_2_19_iii-4.0.0.jar

However, if you run your application, you will get the following output and cache status:

Cache MISS for (3,5)
(1 + 2i) + (2 + 3i) = (3 + 5i)
Cache HIT for (3,5)
(5 + 8i) - (2 + 3i) = (3 + 5i)

This is because the Spring agent advises only the Complex(int,int) constructor calls made by beans declared in the Spring IoC container. As the complex operands are created in the Main class, the Spring agent will not advise their constructor calls.

Define Events Using ApplicationEvent

The first step of enabling event-based communication is to define the event. Suppose you want a cashier bean to publish a CheckoutEvent after the shopping cart is checked out. This event includes a checkout time property.

package com.apress.springrecipes.shop;

import org.springframework.context.ApplicationEvent;

import java.util.Date;

public class CheckoutEvent extends ApplicationEvent {

    private final ShoppingCart cart;
    private final Date time;

    public CheckoutEvent(ShoppingCart cart, Date time) {
        super(cart);
        this.cart=cart;
        this.time = time;
    }

    public ShoppingCart getCart() {
        return cart;
    }

    public Date getTime() {
        return this.time;
    }
}

Publish Events

To publish an event, you just create an event instance and make a call to the publishEvent() method of an application event publisher, which becomes accessible by implementing the ApplicationEventPublisherAware interface.

package com.apress.springrecipes.shop;
...
import org.springframework.context.ApplicationEventPublisher;
import org.springframework.context.ApplicationEventPublisherAware;

public class Cashier implements ApplicationEventPublisherAware {
    ...
    private ApplicationEventPublisher applicationEventPublisher;

    public void setApplicationEventPublisher(
        ApplicationEventPublisher applicationEventPublisher) {
        this.applicationEventPublisher = applicationEventPublisher;
    }

    public void checkout(ShoppingCart cart) throws IOException {
        ...
        CheckoutEvent event = new CheckoutEvent(this, new Date());
        applicationEventPublisher.publishEvent(event);
    }
}

Or you could simply autowire it on a field property.

package com.apress.springrecipes.shop;
...
import org.springframework.context.ApplicationEventPublisher;

public class Cashier {
    ...
    @Autowired
    private ApplicationEventPublisher applicationEventPublisher;

    public void checkout(ShoppingCart cart) throws IOException {
        ...
        CheckoutEvent event = new CheckoutEvent(cart, new Date());
        applicationEventPublisher.publishEvent(event);
    }
}