Spring Learning Notes (vi) Advanced assembly _spring for assembly beans---

This series blog is a learning note for the spring in Action book

This blog post is a high-level assembly of the Assembly Bean, which includes the scope of the ambiguous/bean of the environment and the profile/conditional bean/processing automatic assembly. I. Environment and Profile

One of the big challenges we have in developing software is that we migrate applications from the development environment to the production environment. Some of the practices of the development environment may not be appropriate for the production environment, even if the migration past is not working properly. Database configuration/encryption algorithms and the integration of external systems are examples of what happens when you deploy across environments.

The following is an example of a database to analyze this situation.

Now we need to create a DataSource Bean, in the development environment, use an embedded database to greatly improve the development efficiency, reduce the complexity of datasource, and can make every time the database is started, it is in a given state. Like what:

Program 1: DataSource Bean for development period

@Bean (Destroymethod = "shutdown") public
DataSource DataSource () {return
    new Embeddeddatabasebuilder ()
            . Addscript ("Classpath:schema.sql")
            . Addscript ("Classpath:test-data.sql"). Build ();

Using Embeddeddatabasebuilder back to build an embedded hypersonic database, its schema is defined in Schema.sql, and the test data is loaded by the country test-data.sql.
This datasource is useful when we run integration tests in a development environment or launch applications for manual testing.

Although the datasource created by an embedded database is ideal for a development environment, this is a bad choice for a production environment. In a production environment, as much as we want to use Jndi to get a datasource from the container, the following @bean method is more appropriate in such a scenario.

Program 2: DataSource beans in a production environment

@Bean public
DataSource DataSource () {
    Jndiobjectfactorybean Jndiobjectfactorybean = new Jndiobjectfactorybean ();
    Jndiobjectfactorybean.setjndiname ("jdbc/myds");
    Jndiobjectfactorybean.setresourceref (true);
        Jndiobjectfactorybean.setproxyinterface (javax.sql.DataSource.class);

    Return (DataSource) Jndiobjectfactorybean;
}

Getting DataSource through Jndi allows the container to decide how to create this datasource, even including a connection pool that switches to container management. However, the DataSource of Jndi management is more appropriate for the production environment, which can create unnecessary complexity for a simple integration and development environment.

The DataSource () methods are different, although they all generate a bean of type Javax.sql.DataSource. But their similarities are limited. Two methods use a completely different policy to generate the DataSource Bean.

DataSource that are generated in different ways show that a bean will vary in different environments. We have to have a way to configure DataSource so that it chooses the most appropriate configuration in each environment.

One solution is to configure each bean in a separate configuration class (or XML file), and then determine which configuration to deploy to the deployable application during the build phase (possibly using MAVEN or profiles). The problem with this approach is to reconstruct the application for each environment.

Fortunately, the solution provided by spring does not need to be rebuilt. 1. Configure Profile Bean in Javaconfig

With different ways to generate different versions of beans in different environments, spring provides a strategy to determine which version of the Bean is created at run time. The result is that the same deployment unit (and possibly the war file) can be applied to all environments, and there is no need to rebuild the application.

Spring provides the functionality of Bean profile. To use profile, you first need to organize all current versions of the bean definition into one or more profiles, and when you deploy the application to a specific environment, just make the corresponding profile active (active).

In a Java configuration, you can use the @profile annotation to specify which profile a bean belongs to. For example, in a configuration class, the Databsource of an embedded database might be configured as follows:

Program 3:dev Profile

@Configuration
@Profile ("dev")  //The profile ID is the dev public
class Developmentprofileconfig {
    @Bean ( Destroymethod = "shutdown") public
    DataSource DataSource () {return
        new Embeddeddatabasebuilder ()
                . Addscript ("Classpath:schema.sql")
                . Addscript ("Classpath:test-data.sql"). Build ();

With the above code we can note that the @profile annotation is applied at the class level, and it tells Spring that the bean in the configuration class is created only when the dev profile is activated. If Dev profile is not activated, all methods with @bean annotations in this javaconfig will be ignored.

@Profile annotation inside the parameter dev is the profile configuration class ID for dev.

Similarly, the configuration classes that apply to the production environment are as follows:

Program 4:prod Profile

@Configuration
@Profile ("prod") public
class Productionprofileconfig {
    @Bean public
    DataSource DataSource () {
        Jndiobjectfactorybean Jndiobjectfactorybean = new Jndiobjectfactorybean ();
        Jndiobjectfactorybean.setjndiname ("jdbc/myds");
        Jndiobjectfactorybean.setresourceref (true);
        Jndiobjectfactorybean.setproxyinterface (javax.sql.DataSource.class);

        Return (DataSource) Jndiobjectfactorybean
    }
}

In addition to being able to use the @profile annotations above for class use, starting with Spring3.2, we also support the use of @profile at the method level so that we can write Dev and prod in a javaconfig.

Program 5: @Profile annotations Implementation of bean assembly based on active profile

@Configuration public
class Datasourceconfig {
    @Bean (Destroymethod = "shutdown")
    @Profile ("Dev"
    ) Public DataSource DataSource () {return
        new Embeddeddatabasebuilder ()
                . Addscript ("Classpath:schema.sql")
                . Addscript ("Classpath:test-data.sql"). Build ();

    @Bean
    @Profile ("prod") public
    DataSource Jndisource () {
        Jndiobjectfactorybean Jndiobjectfactorybean = New Jndiobjectfactorybean ();
        Jndiobjectfactorybean.setjndiname ("jdbc/myds");
        Jndiobjectfactorybean.setresourceref (true);
        Jndiobjectfactorybean.setproxyinterface (javax.sql.DataSource.class);

        Return (DataSource) Jndiobjectfactorybean
    }
}

In this way, we use @profile annotations at the method level so that multiple profiles can be placed in a javaconfig.

It should be noted that although each datasource bean is declared in a profile and only when the specified profile is activated, the corresponding bean is created. However, a possible bean does not specify profile, and such a bean is always created and has no relation to which profile is activated. 2. Configure profile in XML

We can use the @profile annotation in javaconfig, in XML we can use the profile property of <beans> element.

For example, to define an embedded database DataSource Bean that applies to the development phase in XML, we can create the following XML file.

Program 6: Configure the profile Bean in the XML file

<?xml version= "1.0" encoding= "UTF-8"?> <beans xmlns=
"Http://www.springframework.org/schema/beans"
       xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xmlns:jdbc= "http://www.springframework.org/schema/ JDBC "
       xsi:schemalocation=" Http://www.springframework.org/schema/beans Http://www.springframework.org/schema /beans/spring-beans.xsd Http://www.springframework.org/schema/jdbc http://www.springframework.org/schema/jdbc/ Spring-jdbc.xsd "
       profile=" dev ">

    <jdbc:embedded-database id=" DataSource ">
        <jdbc:script location= "Classpath:schema.sql"/>
        <jdbc:script location= "Classpath:test-data.sql"/> </jdbc
    : Embedded-database>

</beans>

We can also declare multiple profile beans in an XML file, just like the javaconfig above.

Program 7: Declare multiple profile beans in an XML file

<?xml version= "1.0" encoding= "UTF-8"?> <beans xmlns= "Http://www.springframework.org/schema/beans" Xmlns:xs I= "Http://www.w3.org/2001/XMLSchema-instance" xmlns:jdbc= "Http://www.springframework.org/schema/jdbc" xmlns:jee= "Http://www.springframework.org/schema/jee" xsi:schemalocation= "Http://www.springframework.org/schema/beans http ://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/jdbc http:// Www.springframework.org/schema/jdbc/spring-jdbc.xsd Http://www.springframework.org/schema/jee http://  Www.springframework.org/schema/jee/spring-jee.xsd "> <beans profile=" dev "> <jdbc:embedded-database Id= "DataSource" > <jdbc:script location= "classpath:schema.sql"/> <jdbc:script locatio n= "Classpath:test-data.sql"/> </jdbc:embedded-database> </beans> <beans profile= "PR Od "> <jee:jndi-lookup id=" DataSource "Jndi-name=" JdbC/mydatabase "resource-ref=" true "proxy-interface=" Javax.sql.DataSource "/> </beans> </beans>

3. Activate profile

Now that we've configured the Prifile bean in a variety of ways, let's take a look at how different profile beans are used in different environments

When spring determines which profile is active, it needs to rely on two separate properties: Spring.profiles.active and Spring.profiles.default.

If the value of the active property is set, spring activates the active corresponding profile Bean; If you do not set an active value, spring finds the value corresponding to the default and activates the corresponding profile Bean; If the default value is not set, then spring activates only those beans that are not defined in profile.

There are several ways to set two values: (1) as initialization parameters for Dspatcherservlet; (2) As the context of Web application; (3) as a Jndi entry; (4) as an environment variable; (5) As a system attribute of the JVM; (6) On the integrated test class, use the @activeprofiles annotation setting

One way the authors recommend this is to set the value of default to the profile of the development environment using the Dispatcherservlet parameter, and then use the System Properties/environment variables to set up the application when deploying to the appropriate environment. (1) Set the default profile

The following example demonstrates setting the value of default in Web.xml:

Program 8: Set the value of default in Web.xml

<?xml version= "1.0" encoding= "UTF-8"?> <web-app xmlns= "Http://xmlns.jcp.org/xml/ns/javaee" HT Tp://www.w3.org/2001/xmlschema-instance "xsi:schemalocation=" Http://xmlns.jcp.org/xml/ns/javaee HTTP://XMLNS.JCP . Org/xml/ns/javaee/web-app_3_1.xsd "version=" 3.1 > <!--maven is automatically generated when the version of the Web.xml is 2.3, so some configuration node idea will not recognize it,- -> <!--So we're going to add a 3.1, we can copy this file directly in the future when we use it. .--> <display-name>archetype Created Web application& Lt;/display-name> <!--welcome pages--> <welcome-file-list> &LT;WELCOME-FILE&GT;INDEX.JSP&L
        T;/welcome-file> </welcome-file-list> <!--(1) Set the default profile--> for the context <context-param> <param-name>ContextConfigLocation</param-name> <param-value>dev</param-value> </co ntext-param> <!--configuration Springmvc dispatcherservlet--> <servlet> <servlet-name>springmvc&
    Lt;/servlet-name>    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param&gt
            ;
            <!--Configure Dispatcher.xml as an MVC profile--> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/mvc-dispatcher-servlet.xml</param-value> </init-param> <!--(2 ) to set the default profile--> <init-param> <param-name>spring.profiles.default</param-nam for the servlet e> <param-value>dev</param-value> </init-param> <load-on-startup>1& lt;/load-on-startup> <async-supported>true</async-supported> </servlet> <servlet-m
    Apping> <servlet-name>springMVC</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> <!--to add Applicationcontext.xml to the configuration file, this XML file is now nothing, temporarily do not add also can--> <context-para
    M>    <param-name>contextConfigLocation</param-name> <param-value>/web-inf/applicationcontext.xml& Lt;/param-value> </context-param> <listener> <listener-class>org.springframework.web. Context. Contextloaderlistener</listener-class> </listener> </web-app>

The code above is the full configuration of the current Web.xml, where (1) (2) is our default profile setting.
Default set in this way, all developers can get the application source code from version control software, and use the development environment's settings (such as embedded database) to run codes without the need for additional configuration.

Then when the program is deployed in the appropriate environment, then use the appropriate way to activate the corresponding profile. (2) Activate the appropriate profile for testing

We can use the @activeprofiles annotation to activate the corresponding profile at runtime.
For example, the following code fragment:
Program 9: Activate profile with @activeprofile annotation

@RunWith (Springjunit4classrunner.class)
@ContextConfiguration (classes = {Persistencetestconfig.class})
@ Activeprofiles ("Dev") public
class Activeprofile {
    //...
}

Two. A conditional bean

Sometimes we face the need for a bean to be created after another bean is created, and Spring provides a scenario for this conditional configuration: Using the @conditional annotation, it can be used with a @bean annotation method, If the given condition evaluates to true, the bean is created, otherwise the bean is ignored.

For example, now there is a Magicbean class, and we want spring to instantiate this class only when the Magic ambient property is set, and Magicbean will be ignored if there is no such class in the environment.

Program 10: Conditional Configuration Bean

@Configuration public
class Magicconfig {
    @Bean
    @Conditional (magicexistscondition.class)
    public Magicbean Magicbean () {return
        new Magicbean ();
    }
}

The class that is set to the @conditional annotation must implement the condition interface, and the code for the condition interface is as follows:

Public interface condition{Public
    boolean matches (Conditioncontext Conditioncontext, Annotatedtypemetadata Annotatedtypemetadata) {
    }
}

Program 11:magicexistscondition

public class Magicexistscondition implements Condition {public
    Boolean matches (Conditioncontext Conditioncontext , Annotatedtypemetadata annotatedtypemetadata) {
        Environment environment = conditioncontext.getenvironment ();
        Return Environment.containsproperty ("Magic");
    }

In the above program, the Matchs () method obtains the Environmen object through the given Conditioncontext object, and uses this object to check whether there is an ambient property named Magic in the environment. 1. Understanding of Conditioncontext and Annotatedtypemetadata

We're using just conditioncontext environmen, and in essence, Conditioncontext can do a lot more. Conditioncontext is an interface, let's take a look at what it has:

public interface conditioncontext{
    beandefinitionregistry getregistry ();
    Configurablelistablebeanfactory getbeanfactory ();
    Environment getenvironment ();
    Resourceloader Getresourceloader ();
    ClassLoader getClassLoader ();
}

With Conditioncontext, we can do the following: Check the definition of the bean with the help of the Beandefinitionregistry returned by GetRegistry (); Check whether the bean exists or even probe the bean's properties by using the Configurablelistablebeanfactory returned by Gebeanfactory (); Check whether the environment variable exists and what its value is by using the environment returned by Getenvironment (); Read and probe the resources loaded by the Resourceloader returned by Getresourceloader (); Loads and checks for the existence of a class by using the ClassLoader returned by getClassLoader ().

And Annotatedtypemetadata can let us check with @bean annotation method on what other annotations, about the Annotatedtypemetadata interface content is not too much description, when needed to check the corresponding documents on it.

It is noteworthy that, starting with spring 4, @Profile annotations have been refactored to make them based on @conditional and condition implementations. Among them, the reference profilecondition as the implementation of condition. The code for the @profile annotation and the Profilecondition implementation code are not posted here. Three. Deal with the ambiguity of automatic assembly

I don't know if you found out in front of the automatic assembly practice that the problem is that when multiple beans meet the assembly conditions, they throw an exception when the test runs. That is to say, spring is ambiguous when assembling, and it does not know which of these two beans should fit in the assembly condition.

To illustrate this ambiguity, let's look at an example:
In the Eat class There are Setdessert () methods that use the @autowired annotation annotation:

Program 12: Automatic assembly of the Eat class

@Component public
class Eat {
    private dessert dessert;

    @Autowired public
    void Setdessert (dessert dessert) {
        This.dessert = dessert;
    }
}

Dessert is an interface that has several implementation classes:

@Component public
class Cake implements dessert {
}
@Component public
class Cookies implements Dessert {
}
@Component public
class Icecream implements dessert {
}

The above three classes all implement the dessert interface, and all use the @component annotation, can be assembled into the Setdessert () method, then how can we determine which one is assembled? 1. Solution One: marking the preferred bean

Emmmm, I like icecream most of the three desserts, so I'm going to set icecream as the preferred bean to be assembled.
Use the @primary annotation to mark a bean as the preferred bean, as follows: (1) declaring the preferred bean in automatic assembly

@Component
@Primary Public
class Icecream implements dessert {
}

(2) declaring preferred Bean in javaconfig

@Configuration public
class Eatconfig {
    @Bean
    @Primary public
    Dessert icecream () {return
        new Icecream ();
    }

(3) Marking the preferred bean in XML

<bean id= "icecream" class= "AdvancedAssembly.ConditionalBean.Dessert.IceCream"
        primary= "true"/>

2. Solution Two: Limit automatic assembly of beans

The solution for the preferred bean above is straightforward, but when there are two preferred beans, there is no way to choose a "more preferred" bean.
So spring offers another, more powerful workaround: Using qualifiers to qualify automatically assembled beans.

The spring qualifier is capable of narrowing operations on all optional beans, making it possible to end up with only one operation-compliant bean. Using @qualifier annotations is the primary way to use qualifiers. (1) Using native qualifier notation

Let's take a look at how to use qualifiers in one example:

Program 13: Using qualifier notation

@Component public
class Eat {
    private dessert dessert;

    @Autowired
    @Qualifier ("icecream") public
    void Setdessert (dessert dessert) {
        This.dessert = dessert;
    }
}

The icecream Bean can be matched by the "icecream" inside the @qulifier () callout. You can interpret "icecream" as the ID of the bean you want to inject. In essence, however, this "icecream" qualifier is used to match a bean with a qualifier of icecream, because each bean has its own default qualifier, which the Fummer considers the bean's ID, so @qualifier ("icecream") is to inject the icecream bean with the default qualifier into the Setdessert () method.

But here's another problem: if you change the name of the Icecream class to Strawberryicecream now, automatic assembly will fail. This means that the qualifier to be specified on the Setdessert () method is tightly coupled to the name of the bean to be injected, which is not in line with the idea of spring, so we can solve the problem by creating a custom qualifier. (2) using a custom qualifier

Instead of using the bean default qualifier, we can customize the qualifier for the Bean. You can customize qualifiers by adding @qualifier annotations before the bean's declaration. Like what:

@Component
@Qualifier ("cold") public
class Icecream implements dessert {
}

Then, in the @qualifier annotation of the Setdessert () method in Javaconfig, we can use our custom qualifier.

@Component public
class Eat {
    private dessert dessert;

    @Autowired
    @Qualifier ("cold") public
    void Setdessert (dessert dessert) {
        This.dessert = dessert;
    }
}

In this way, we can change the icecream bean without worrying that the changes will destroy the automatic assembly.
Custom qualifiers are usually named as the bean's characteristics, such as the cold that we specified above is the icecream feature. (3) Use a custom qualifier annotation

We have defined the qualifier above, but there are still some problems, such as how many beans have the same characteristics (cold), or the ambiguity of the problem, to further reduce the scope of the bean.
We have previously defined qualifiers and now we can customize qualifier annotations.

Instead of using @qualifier ("cold") in Icecream, you customize a @cold annotation.

Program 14: Customizing a @cold callout

@Target ({elementtype.constructor, Elementtype.field, 
        Elementtype.method, elementtype.type})
@Retention ( Retentionpolicy.runtime)
@Qualifier public
@interface Cold {}

Using @cold annotations in Icecream

@Component
@Cold Public
class Icecream implements dessert {
}

Using @cold in Eat

@Component public
class Eat {
    private dessert dessert;

    @Autowired
    @Cold public
    void Setdessert (dessert dessert) {
        This.dessert = dessert;
    }
}

Callouts like @cold, we can customize multiple according to our own requirements, and use it according to our own requirements, that is, you can use multiple custom qualifiers to qualify a bean. Four. Scope of the Bean

By default, all the beans in the spring application context are created as a single case. In other words, a bean, no matter how many times it is injected into the other bean, is injected with the same instance each time.

In most cases, a single instance of the bean is an ideal scenario. However, sometimes you will find that the classes you use are variable, that they maintain some state, so reuse is unsafe. In this case, it is unreasonable to declare the class as a single bean, because the object will be contaminated and unexpected problems will arise later when reused.

With this in mind, Spring has a variety of scopes to choose from when creating beans: 1. Single case (Singleton): In the entire application, only one instance of the bean is created; 2. Prototype (Prototype): A new bean instance is created each time it is injected or acquired through the spring application context; 3. Session: In a Web application, create a bean instance for each session; 4. Request (requests): In a Web application, create a bean instance for each request. 1. Set scope for Bean

A single example is the default scope, and if you select a different scope, use the @scope annotation, which can be used with component or @bean. Like what:

Program 15: Set the scope in Notepad notebook bean

@Component
@Scope (configurablelistablebeanfactory.scope_prototype) public
class Notepad {
}

The code that is set up through XML is as follows:

<bean id= "Notapad" class= "AdvancedAssembly.Scope.Notepad" scope= "prototype"/>
          

Accordingly, the scope is also set in the Notepadconfig.

Program 16: Set the scope in Notepadconfig

@Configuration public
class Notepadconfig {
    @Bean
    @Scope (configurablelistablebeanfactory.scope_ PROTOTYPE) Public
    Notepad Notepad () {return
        new Notepad ();
    }
}

Above in the @scope annotation uses the Configurablelistablebeanfactory scope_prototype, actually also may write @scope ("PROTOTYPE"), but uses the above kind of writing does not have the error easily, So try to use the above wording.

Here we are. Session and request scope (1) Session scope

A typical example in E-commerce is a shopping cart. Imagine if the shopping cart is a single case, that is to say, all users will share a shopping cart, which is not appropriate. But if you set it as a prototype scope, also said that the user each browsing a page has a corresponding shopping cart, the user will add a coat to the shopping cart, and then to another page to add a pair of trousers to the shopping cart, wait until the payment, do you have to go to the top and trousers page to pay?

is obviously not appropriate. The right approach should be that each user has a shopping cart.
In this case, we can set the shopping cart Bean as the session scope.

Program 17: Session Scope Shopping Cart Bean

@Component
@Scope (value = webapplicationcontext.scope_session, 
        proxymode = scopedproxymode.interfaces) Public
class ShoppingCart {
}

This sets value to Webapplicationcontext.scope_session, which tells Spring to create a ShoppingCart Bean for each session in the Web application. This means that the ShoppingCart bean is more than a case in the entire application, and in each session it is a single case.

There is also another attribute Proxymode in scope, which is set to scopedproxymode.interfaces, which resolves the problem of injecting a session or request-scoped bean into a single instance bean.
Before describing the Proxymode property, take a look at the scenario where Proxymode solves the problem.

Now you want to inject the ShoppingCart bean into the setter method of a single storeservice bean, as follows:

@Component public
class Storeservice {
    private shoppingcart ShoppingCart;

    @Autowired public
    void Setshoppingcart (ShoppingCart shoppingcart) {
        this.shoppingcart = ShoppingCart;
    }
}

Because the Storeservice bean is a single case, it is created when the spring application context is loaded, and when it is created, spring attempts to inject the ShoppingCart bean into the storeservice bean. However, the ShoppingCart Bean is a session-scoped and does not exist until a user enters the system, and the ShoppingCart instance is not present until the session is created.

In addition, there will be multiple ShoppingCart instances in the system, one for each user. It's not like we let spring inject a fixed shoppingcart bean into a storeservice bean. What we want is that when Storeservice handles the shopping cart feature, the ShoppingCart bean it uses is exactly the one that corresponds to the current session.

Now there are two problems to be solved: when the Storeservice Bean is created, the ShoppingCart bean does not exist and cannot be satisfied; ShoppingCart beans are multiple, and Storeservice is a single example.

Spring uses proxy mode, and we can look at a picture first:

Now take a detailed look at how using proxy mode solves the above two problems:

Solve the problem one:
When the Storeservice Bean is created and the ShoppingCart bean does not exist, spring injects an agent of a shoppingcart bean into the storeservice bean. This agent exposes the same method as the ShoppingCart bean, so the Storeservice Bean considers the proxy to be a shoppingcart bean, which resolves the storeservice The beginning of the bean creation and the ShoppingCart Bean does not have a problem that does not satisfy dependencies.

Solve the problem two:
When the Storeservice bean really needs to invoke the ShoppingCart Bean's method, the agent resolves it and delegates the call to the true ShoppingCart bean in the corresponding session scope.

Now, we're going to talk about the Proxymode attribute with two solutions to the problem. As the configuration shows, the Proxymode property is set to Scopedproxymode.interfaces, indicating that the proxy implements the ShoppingCart interface and delegates the call to the true implementation bean.

In the above code, ShoppingCart is an interface, the agent needs to implement this interface, which is the ideal proxy mode. But if ShoppingCart is a class, spring has no way to create an agent-based proxy. At this point, it must use Cglib to generate a class-based proxy. So, if the bean type is a concrete class, we have to set the Proxymode property to ScopedProxyMode.TARGET.CLASS to represent the way to create the proxy by generating the target class extension.

The session scope Bean assembly is described in detail, and the request scope is similar, and the request scope bean should also be injected as a scope proxy. 3. Declaring a scope agent in XML

If you need to use XML to declare a session or a request-scoped bean, you need to set the scope of the bean using the <bean> element's scope property. But how do you specify a proxy mode?

We use a new element of the spring AOP namespace to specify the proxy pattern:

<bean id= "cart" class= "AdvancedAssembly.Scope.ShoppingCart"
                    scope= "Session" >
            <aop:scoped-proxy Proxy-target-class= "false"/>
</bean>

<aop:scoped-proxy> is the spring XML configuration element that is the same as the Proxymode property feature of the @scope annotation. It tells spring to create a scope proxy for the bean. By default, It uses Cglib to create a proxy for the target class. But we can also set the Proxy-target-class property to False, which in turn requires it to generate an interface based proxy.