Hongliang's notebook

To create an  AOP proxy in Spring, you should use the ProxyFactoryBean. This gives complete control over the pointcuts and advice that will apply, and their ordering. However, there are simpler options that are preferable if you don't need such control. Within the ProxyFactoryBean, you need to provide some property values.

proxyInterfaces – where you specify which interface you would like to create proxy for

interceptorNames – a list of inceptor names. The interceptor will be used to do some business before and after running the method.

target – A reference to the implementation class

<bean id="documentViewService" class="org.springframework.aop.framework.ProxyFactoryBean">

<property name="proxyInterfaces"

            value="com.hongliang.DocumentViewService"/>

    <property name="interceptorNames">

        <list>

             <value>documentViewServiceInterceptor</value>

        </list>

    </property>

    <property name="target">

        <ref bean="documentViewServiceImpl"/>

    </property>

</bean>

Then you can specify your interceptor class with the logic that you would like to add to the method while accessing, such as security check.

<bean id="documentViewServiceInterceptor"

class="com.hongliang.DocumentViewServiceInterceptor">

    <property name="documentViewAccessDecisionManager">

        <ref local="documentViewAccessDecisionManager"/>

    </property>

    <property name="accessDecisionManager">

        <ref local="documentViewAccessDecisionManager"/>

</property>

<property name="exemptMethods">

     <set>

            <value>getIssues</value>

        </set>

    </property>

</bean>

The interceptor class has predefined some properties, which includes the name of the method that should be excluded to apply the logic specified by the interceptor. In order to prevent some redundant work, you might want to exclude those methods before invoking them. To do this, you need to specify it inside the beforeInvocation() method.

public class DocumentViewServiceInterceptor extends MethodSecurityInterceptor implements Serializable {

private DocumentViewAccessDecisionManager documentViewAccessDecisionManager;

public InterceptorStatusToken beforeInvocation(Object object) {

            //skip the exempt methods

}

public Object afterInvocation(InterceptorStatusToken token, Object returnedObject) {

Authentication authenticated = SecurityContextHolder.getContext().getAuthentication();

try {

    this.documentViewAccessDecisionManager.decide(authenticated, returnedObject, null);

} catch (InsufficientAuthenticationException e) {

               //your solution if user not authorised 

}

}                                          

}

As you can see from the preceding code, we use documentViewAccessDecisionManager which implements AccessDecisionManager to decide whether user have the authorisation to access the current method. If user does not authorised to access, an InsufficientAuthenticationException will be thrown. If such an exception is caught in the interceptor class, you can specify your solution in the catch clause.

Reference:

http://static.springframework.org/spring/docs/1.2.x/reference/aop.html

http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-proxying

The official summary of annotation is as follow: As of release JDK 5.0, the platform has a general purpose annotation (also known as metadata) facility that permits you to define and use your own annotation types.

Annotation type declarations are similar to normal interface declarations. An at-sign (@) precedes the interface keyword. Each method declaration defines an element of the annotation type. Method declarations must not have any parameters or a throws clause. Return types are restricted to primitives, String, Class, enums, annotations, and arrays of the preceding types. Methods can have default values. Here is an example annotation type declaration.

/**

 * Describes the Request-For-Enhancement(RFE) that led

 * to the presence of the annotated API element.

 */

public @interface RequestForEnhancement {

    int    id();

    String synopsis();

    String engineer() default "[unassigned]";

    String date();    default "[unimplemented]";

}

In annotations with a single element, the element should be named value, as shown below:

/**

 * Associates a copyright notice with the annotated API element.

 */

public @interface Copyright {

    String value();

}

Applying Annotation with other framework

Annotation has been extensively used in Spring and other frameworks. In this note, I am only introducing very small portion based on a unit test demonstration.

@RunWith(SpringJUnit4ClassRunner.class)

@ContextConfiguration(locations = {"/test-datasources.xml", "/ioc/app-config.xml"})

public abstract class AbstractAnnotationDaoTest {

    @Autowired

    public SessionFactory sessionFactory;

}

·          @RunWith  When a class is annotated with @RunWith or extends a class annotated with @ RunWith, JUnit will invoke the class it references to run the tests in that class instead of the runner built into JUnit.

·          @ContextConfiguration defines class-level metadata which can be used to instruct client code with regard to how to load and configure an ApplicationContext. Variable “locations” specifies where to load it

·          @Autowired more details are explained later. Basically, BeanFactory will be autowired into a field, constructor argument, or method parameter that is expecting the BeanFactory type as long as the field, constructor, or method in question carries the @Autowired annotation. in the preceding example, the value of sessionFactory will injected, based on its definition in the app-config.xml file. (This property is just for demonstration purpose and not used in the following sub class)

public class NewsDaoTest extends AbstractAnnotationDaoTest {

    @Resource

    private NewsDao newsDao;

    @Test

    public void getLastMonthNews () {

        List<Document> list = this.newsDao.getLastMonthNews();

        assertNotNull(list);

    }

}

·          @Resource is from Java annotation, you can replace with @autowired from spring framework as introduced above.  I couldn’t see the virtual difference between the two. The description of @Resource from its official JavaDoc is as follow: The Resource annotation marks a resource that is needed by the application.  This annotation may be applied to an application component class, or to fields or methods of the component class.  When the annotation is applied to a field or method, the container will inject an instance of the requested resource into the application component when the component is initialized.

·          @Test tells JUnit that the public void method to which it is attached can be run as a test case. To run the method, JUnit first constructs a fresh instance of the class then invokes the annotated method.

Autowiring collaborators explanation on Spring framework site

The Spring container is able to autowire relationships between collaborating beans. This means that it is possible to automatically let Spring resolve collaborators (other beans) for your bean by inspecting the contents of the BeanFactory. The autowiring functionality has five modes. Autowiring is specified per bean and can thus be enabled for some beans, while other beans will not be autowired

Note that explicit dependencies in property and constructor-arg settings always override autowiring. Please also note that it is not currently possible to autowire so-called simple properties such as primitives, Strings, and Classes (and arrays of such simple properties).

Reference

http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-autowired-annotation  

http://static.springframework.org/spring/docs/2.5.x/reference/metadata.html

http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html

MultiActionController VS ParameterizableViewController

Have discussed “Validation with Spring MVC SimpleFormController” in the earlier note, which demonstrated you how handy it is to duel with forms. In this note, I would like to introduce another two handy controllers: MultiActionController and ParameterizableViewController.

ParameterizableViewController

The official JavaDoc introduced: “This controller offers an alternative to sending a request straight to a view such as a JSP. The advantage here is that the client is not exposed to the concrete view technology but rather just to the controller URL”. (Which controller is not?)  The advantage for using this controller is that you can simply set the view page straight away in the configuration rather than doing any coding in the controller.

MultiActionController is a bit more complex to configure, but would save you loads of time from writing many controllers that have common functions individually. multi-action controller with which you aggregate multiple actions into one controller, grouping functionality together.

There are two features offered by MutliActionController

The following example demonstrates how to apply the methodNameResolver feature.

<bean id=" multiTestController " class="com.hongliang.MultiTestController">

    <property name="methodNameResolver">

        <bean class="org.springframework.web.servlet.mvc.multiaction.ParameterMethodNameResolver">

            <property name="methodParamNames">

                <list>

                    <value>viewBooks</value>

                    <value>viewArticles</value>

                </list>

            </property>

            <property name="logicalMappings">

                <props>

                    <prop key=" viewBooks ">displayBooks</prop>

                    <prop key="viewArticles">displayArticles</prop>

                </props>

            </property>

            <property name="defaultMethodName">

                <value> displayBooks </value>

            </property>

        </bean>

    </property>

</bean>

The MethodNameResolver is supposed to resolve method names based on the request coming in. There are three resolvers at your disposal, but of course you can implement more of them yourself if you want to. The explanation from spring official reference is as below

·         ParameterMethodNameResolver - capable of resolving a request parameter and using that as the method name (http://www.sf.net/index.view?testParam=testIt will result in a method testIt(HttpServletRequest, HttpServletResponse) being called). The paramName configuration parameter specifies the parameter that is inspected).

·         InternalPathMethodNameResolver - retrieves the filename from the path and uses that as the method name (http://www.sf.net/testing.view will result in a method testing(HttpServletRequest, HttpServletResponse) being called).

·         PropertiesMethodNameResolver - uses a user-defined properties object with request URLs mapped to methodnames. When the properties contain /index/welcome.html=doIt and a request to /index/welcome.html comes in, the doIt(HttpServletRequest, HttpServletResponse) method is called. This method name resolver works with the PathMatcher, so if the properties contained /**/welcom?.html, it would also have worked!

The preceding example applied ParameterMethodNameResolver. In practice, when my controller called it will check the reqest url. If it includes the parameter viewBooks, then displayBooks() method will be called; If viewArticles is included, then displayArticles() will be called; If neither is included, the default (displayBook()) will be called.

public class SpecialReportsController extends MultiActionController {

public ModelAndView displayBooks (HttpServletRequest request, HttpServletResponse response) throws Exception {

                this.commonFunction();

return new ModelAndView(“book.jsp”);

                }

public ModelAndView displayArticles (HttpServletRequest request, HttpServletResponse response) throws Exception {

                this.commonFunction();

                                 return new ModelAndView(“article.jsp”);

                }

                private void commonFunction(){

                                …..

}

}

Reference:

http://static.springframework.org/spring/docs/1.2.9/reference/mvc.html

http://blog.csdn.net/xxxatt/archive/2007/09/11/1781025.aspx