Category Archives: JAVA

java code static check tools

JAVA

checkstyle：
http://checkstyle.sourceforge.net/

Google Java Style
http://checkstyle.sourceforge.net/reports/google-java-style.html

Findbugs
PMD
Checkstyle
Lint4J
Classycle
JDepend
SISSy
Google Codepro

Open Source or Free Tools Of This Type
Google CodeSearchDiggity – Utilizes Google Code Search to identifies vulnerabilities in open source code projects hosted by Google Code, MS CodePlex, SourceForge, Github, and more. The tool comes with over 130 default searches that identify SQL injection, cross-site scripting (XSS), insecure remote and local file includes, hard-coded passwords, and much more. Essentially, Google CodeSearchDiggity provides a source code security analysis of nearly every single open source code project in existence – simultaneously.
FindBugs – Find Bugs (including some security flaws) in Java Programs
FxCop (Microsoft) – FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements.
PMD – PMD scans Java source code and looks for potential code problems (this is a code quality tool that does not focus on security issues)
PreFast (Microsoft) – PREfast is a static analysis tool that identifies defects in C/C++ programs
RATS (Fortify) – Scans C, C++, Perl, PHP and Python source code for security problems like buffer overflows and TOCTOU (Time Of Check, Time Of Use) race conditions
OWASP SWAAT Project – Simplistic Beta Tool – Languages: Java, JSP, ASP .Net, and PHP
Flawfinder Flawfinder – Scans C and C++
RIPS – RIPS is a static source code analyzer for vulnerabilities in PHP web applications
Brakeman – Brakeman is an open source vulnerability scanner specifically designed for Ruby on Rails applications
Codesake Dawn – Codesake Dawn is an open source security source code analyzer designed for Sinatra, Padrino and Ruby on Rails applications. It can work also for non web application wrote in Ruby programming language
VCG – Scans C/C++, Java, C# and PL/SQL for security issues and for comments which may indicate defective code. The config files can be used to carry out additional checks for banned functions or functions which commonly cause security issues.
Commercial Tools Of This Type
BugScout (Buguroo Offensive Security)

Latest generation source code analysis tool bugScout detects source code vulnerabilities and makes possible an accurate management of the life cycles due to its easy use.

Contrast from Contrast Security

Contrast is not a static analysis tool like these others. It instruments the running application and provides code level results, but doesn’t actually perform static analysis. It monitors the code that is actually running.

IBM Security AppScan Source Edition (formerly Ounce)
Insight (KlocWork)
Parasoft Test (Parasoft)
Pitbull Source Code Control (Pitbull SCC)

Software application designed to solve efficiently application source code control with the appropriate compiled files to ensure integrity prior to placing it into production. Providing added value,allows the analysis of source code to identify if it has a malware that affects the normal functioning of the application.

Seeker (Quotium)

Seeker performs code security without actually doing static analysis. Seeker does Interactive Application Security Testing (IAST), correlating runtime code & data analysis with simulated attacks. It provides code level results without actually relying on static analysis.

Source Patrol (Pentest)
Static Source Code Analysis with CodeSecure™ (Armorize Technologies)
Kiuwan – SaaS Software Quality & Security Analysis (Optimyth)
Static Code Analysis (Checkmarx)
Security Advisor (Coverity)
PVS-Studio (PVS-Studio)
Source Code Analysis (HP/Fortify)
Veracode (Veracode)
Sentinel Source solution (Whitehat)

from:https://www.owasp.org/index.php/Source_Code_Analysis_Tools

Spring MVC Guide and Resources

JAVA, Resource, Spring, ,

 Spring MVC Guide

Step Description
1 Create a Dynamic Web Project with a name HelloWeb and create a package com.tutorialspoint under the src folder in the created project.
2 Drag and drop below mentioned Spring and other libraries into the folder WebContent/WEB-INF/lib.
3 Create a Java class HelloController under the com.tutorialspoint package.
4 Create Spring configuration files web.xml and HelloWeb-servlet.xml under the WebContent/WEB-INF folder.
5 Create a sub-folder with a name jsp under the WebContent/WEB-INF folder. Create a view file hello.jsp under this sub-folder.
6 The final step is to create the content of all the source and configuration files and export the application as explained below.

 

Spring MVC Hello World Example
http://www.tutorialspoint.com/spring/spring_mvc_hello_world_example.htm

 

Download Spring jar package:
http://maven.springframework.org/release/org/springframework/spring/ or http://repo.spring.io/release/org/springframework/spring/

Where can I download Spring Framework jars without using Maven
http://stackoverflow.com/questions/19082860/where-can-i-download-spring-framework-jars-without-using-maven

http://mvnrepository.com

JaCoCo：分析单元测试覆盖率的利器

JAVA, UnitTest,

前言

随着敏捷开发的流行，编写单元测试已经成为业界共识。但如何来衡量单元测试的质量呢？有些管理者片面追求单元测试的数量，导致底下的开发人员投机取巧，编写出大量的重复测试，数量上去了，质量却依然原地踏步。相比单纯追求单元测试的数量，分析单元测试的代码覆盖率是一种更为可行的方式。JaCoCo（Java Code Coverage）就是一种分析单元测试覆盖率的工具，使用它运行单元测试后，可以给出代码中哪些部分被单元测试测到，哪些部分没有没测到，并且给出整个项目的单元测试覆盖情况百分比，看上去一目了然。EclEmma 是基于 JaCoCo 的一个 Eclipse 插件，开发人员可以方便的和其交互。因此，本文先从 EclEmma 入手，给读者一个直观的体验。

回页首

使用 EclEmma 在 Eclipse 中查看单元测试覆盖率

EclEmma 是基于 JaCoCo 的 Eclipse 插件，使用它，开发人员可以直观地看到单元测试的覆盖情况。

安装 EclEmma

打开 Eclipse 的软件市场，在其中搜索 EclEmma，找到后完成安装，如下图所示：

图 1. 安装 EclEmma

图 1. 安装 EclEmma

安装完成后，Eclipse 的工具条里会多出下面这样一个图标：

图 2. Coverage 图标

图 2. Coverage 图标

分析单元测试覆盖率

成功安装 EclEmma 后，就可以试着用它来分析项目的单元测试覆盖率了。为了方便演示，我们使用 Eclipse 创建了一个标准 Java 工程。其中包含一个数学工具类，用来计算三个数中的最大值，代码如下：

清单 1. 数学工具类
package com.dw.math;
public class MathUtil {
   public static int max(int a, int b, int c){
       if(a > b){
           if(a > c){
               return a;
           }else{
               return c;
           }
        }else{
           if(b > c){
               return b;
           }else{
               return c;
           }
        }
    }
}

可以看到，这里的算法稍微有点复杂，使用到了多个条件判断分支，因此，特别适合为其编写单元测试。第一个版本的单元测试如下：

清单 2. 第一个版本的单元测试
package com.dw.math;
import static org.junit.Assert.*;
import org.junit.Test;
  public class MathUtilTest {
    @Test
    public void test_max_1_2_3() {
          assertEquals(3, MathUtil.max(1, 2, 3));
    }
}

试着运行一下单元测试覆盖率分析工具：40.0%！似乎不太理想。展开分析报告，双击后在编辑器里可以看到覆盖情况被不同的颜色标识出来，其中绿颜色表示代码被单元测试覆盖到，黄色表示部分覆盖，红色则表示完全没有覆盖到，如下图所示：

图 3. 单元测试覆盖率报告

图 3. 单元测试覆盖率报告

让我们尝试多加一些单元测试，来改善这种情况，请看下面第二个版本的单元测试：

清单 3. 第二个版本的单元测试
package com.dw.math;
import static org.junit.Assert.*;
import org.junit.Test;
  public class MathUtilTest {
  @Test
  public void test_max_1_2_3() {
      assertEquals(3, MathUtil.max(1, 2, 3));
  }
  @Test
  public void test_max_10_20_30() {
      assertEquals(30, MathUtil.max(10, 20, 30));
  }
  @Test
  public void test_max_100_200_300() {
      assertEquals(300, MathUtil.max(100, 200, 300));
  }
}

测试覆盖率还是 40.0%！虽然我们额外再加了两个测试，但覆盖率没有半点提升，这些单元测试其实是重复的，它们在重复测试同一段代码。如果单纯追求单元测试的数量，那么这无疑会给管理者造成错觉，他们觉得单元测试的数量增加了，软件的质量更有保证了；而对于那些喜欢偷懒的程序员，也蒙混过关，但却给软件质量埋下了隐患。让我们删掉这些重复的单元测试，重新思考一下怎么测试这个方法。

首先我们要测试正常情况，这其中又包含 3 种情况：第一个参数最大，第二个参数最大，以及最后一个参数最大。然后我们还需测试几种特殊情况，比如三个参数相同，三个参数中，其中两个相同。让我们照此思路重新编写单元测试：

清单 4. 第三个版本的单元测试
package com.dw.math;
import static org.junit.Assert.*;
import org.junit.Test;
public class MathUtilTest {
  @Test
  public void test_max_1_2_3() {
      assertEquals(3, MathUtil.max(1, 2, 3));
  }
  @Test
  public void test_max_1_3_2() {
      assertEquals(3, MathUtil.max(1, 3, 2));
  }
  @Test
  public void test_max_3_2_1() {
      assertEquals(3, MathUtil.max(3, 2, 1));
  }
  @Test
  public void test_max_0_0_0(){
      assertEquals(0, MathUtil.max(0, 0, 0));
  }
  @Test
  public void test_max_0_1_0(){
      assertEquals(1, MathUtil.max(0, 1, 0));
  }
}

再次运行单元测试分析工具：75.0%！这次比以前有了很大提升，但是结果还不能令人满意，打开分析报告可以看到，有一个分支还是没有覆盖到，如图所示：

图 4. 单元测试覆盖率报告

图 4. 单元测试覆盖率报告

阅读代码可以看出，这种情况是指第一个参数大于第二个参数，却小于第三个参数，因此我们再增加一个单元测试：

清单 5. 再增加一个单元测试
@Test
public void test_max_2_1_3() {
    assertEquals(3, MathUtil.max(2, 1, 3));
}

再运行一遍单元测试分析工具：100.0%！终于我们的单元测试达到了全覆盖，这样我们对自己开发的代码更有信心了。当然，我们在这里并不是为了单纯的追求这个数字，在增加单元测试覆盖率的诱导下，我们重新理清了测试的步骤，写出了更有意义、更全面的单元测试。而且根据单元测试分析工具给的反馈，我们还发现了先前没有想到的情形。因此，单元测试的覆盖率并不只是一个为了取悦管理者的数据，它实实在在地帮助我们改善了代码的质量，增加了我们对所编写代码的信心。

回页首

给管理者的单元测试覆盖率报告

管理者天生喜欢阅读报告。他们不会屈尊坐在你的办公桌前，让你向他展示 Eclipse 中这一片花花绿绿的东西。而且这份报告对他们至关重要，他们需要用它向上级汇报；年底回顾时，他们也可以兴奋地宣称产品的单元测试覆盖率增加了多少。作为一名开发人员，我们很大一部分工作量就在于满足管理者的这种需求。因此，本节我们讨论如何将 JaCoCo 集成到 Ant 脚本中，生成漂亮的单元测试覆盖率报告。

准备工作

在集成 JaCoCo 前，必须先确保你的 Java 工程有一个可执行的 Ant 构建脚本。一个简单的 Ant 构建脚本一般会执行如下任务：编译（包括编译工程代码和测试代码）、打包和执行单元测试。下面是本文示例 Java 项目所用的 Ant 构建脚本，读者可结合自己的项目及文件路径，在此基础之上进行修改。

清单 6. build.xml
<project name="math" basedir="." default="junit">
 <!--预定义的属性和 classpath -->
 <property name="src.dir" value="src" />
 <property name="test.dir" value="test" />
 <property name="build.dir" value="build" />
 <property name="classes.dir" value="${build.dir}/classes" />
 <property name="tests.dir" value="${build.dir}/tests" />
 <property name="jar.dir" value="${build.dir}/jar" />
 <property name="lib.dir" value="lib" />
 
 <path id="classpath">
     <fileset dir="${lib.dir}" includes="**/*.jar" />
 </path>
 
  <!--清除上次构建 -->
  <target name="clean">
      <delete dir="${build.dir}" />
  </target>
  
  <!--编译代码，包括单元测试 -->
  <target name="compile" depends="clean">
     <mkdir dir="${classes.dir}" />
     <mkdir dir="${tests.dir}" />
     <javac srcdir="${src.dir}" destdir="${classes.dir}" />
     <javac srcdir="${test.dir}" destdir="${tests.dir}">
     <classpath>
     <path refid="classpath" />
     <path location="${classes.dir}" />
     </classpath>
     </javac>
  </target>
  
  <!--打包 -->
  <target name="jar" depends="compile">
     <mkdir dir="${jar.dir}" />
     <jar destfile="${jar.dir}/${ant.project.name}.jar" basedir="${classes.dir}">
     </jar>
  </target>
  
  <!--运行单元测试 -->
  <target name="junit" depends="jar">
     <junit printsummary="yes">
       <classpath>
       <path refid="classpath"/>
       <path location="${classes.dir}" />
       <path location="${tests.dir}" />
       </classpath>
       <batchtest fork="yes">
       <fileset dir="${test.dir}" includes="**/*Test.java"/>
       </batchtest>
     </junit>
  </target>
</project>

集成 JaCoCo

首先需要从 然后就是使用 JaCoCo 官网下载 需要的版本，然后将下载得到的压缩文件解压，将其中的 jacocoant.jar 拷贝至 Java 工程下存放第三方 jar 包的目录，在示例工程里，我有一个和 src 平级的 lib 目录，jacocoant.jar 就放到了这个目录底下，读者可根据自己的项目组织结构做相应调整。然后我们需要在 Ant 构建脚本中定义新的任务：

清单 7. 定义新的构建任务
<taskdef uri="antlib:org.jacoco.ant" resource="org/jacoco/ant/antlib.xml">
<classpath refid="classpath" />
</taskdef>

现在就可以在 Ant 构建脚本中使用 JaCoCo 了。需要注意的是，为了避免命名冲突，需要给 Ant 构建脚本加入新的 XML 命名空间：

清单 8. 加入新的 JaCoCo 命名空间
<project name="math" basedir="." xmlns:jacoco="antlib:org.jacoco.ant" default="junit">

我们主要使用 JaCoCo 的两个任务：首先是jacoco:coverage，用来生成单元测试覆盖率数据，这是一个二进制文件，为了生成从该文件生成报表，我们还要调用另外一个任务jacoco:report，它的输入为jacoco:coverage生成的二进制文件，输出报表。报表有多种格式可选，可以是 HTML、XML、CSV 等。具体的脚本如下：

清单 9. 使用 JaCoCo 生成测试覆盖率和报表
<jacoco:coverage destfile="${build.dir}/jacoco.exec">
  <junit fork="true" forkmode="once" printsummary="yes">
     <classpath>
         <path refid="classpath" />
         <path location="${classes.dir}" />
         <path location="${tests.dir}" />
     </classpath>
     <batchtest fork="yes">
          <fileset dir="${test.dir}" includes="**/*Test.java"/>
     </batchtest>
  </junit>
 </jacoco:coverage>
 
 <jacoco:report>
   <executiondata>
        <file file="${build.dir}/jacoco.exec"/>
   </executiondata>
   <structure name="dw demo">
      <classfiles>
           <fileset dir="${classes.dir}"/>
      </classfiles>
      <sourcefiles encoding="UTF-8">
           <fileset dir="${src.dir}"/>
      </sourcefiles>
   </structure>
  <html destdir="${build.dir}"/>
</jacoco:report>

JaCoCo 的任务定义非常清晰，在这里略作说明。首先需要将原来的junit任务嵌入jacoco:coverage，而且需要指定fork="true"，代表单元测试需要另起一个 JVM 执行，否则 JaCoCo 就会执行失败。destfile="${build.dir}/jacoco.exec"指定生成的测试覆盖率文件输出到什么地方，后面生成报告的时候需要输入该文件的地址。然后就是使用 jacoco:report 生成报告，指定前面任务生成的单元测试覆盖率文件、编译好的类文件以及源代码，最后选择一种格式，这里使用 html，生成报告。打开报告的存放路径，就可以看到如下所示的单元测试覆盖率报告：

图 5. HTML 版的单元测试覆盖率报告

图 5. HTML 版的单元测试覆盖率报告

回页首

和同类产品比较

市面上流行的单元测试覆盖率工具还有 Clover 和 Cobertura。和它们相比，JaCoCo 有如下优势：

  1. JaCoCo 拥有友好的授权形式。JaCoCo 使用了 Eclipse Public License，方便个人用户和商业用户使用。而 Clover 对于商业用户是收费的。
  2. JaCoCo 被良好地集成进各种工具中。在 Java 社区里，很多流行的工具都可以集成 JaCoCo，比如 SonarQube、Jenkins、Netbeans、Eclipse、IntelliJ IDEA、Gradle 等。
  3. JaCoCo 社区非常活跃，它是目前唯一支持 Java 8 的单元测试覆盖率工具。而且关于 JaCoCo 的文档相对较多，降低了学习门槛。

回页首

结束语

本文为大家介绍了如何使用 JaCoCo 分析项目的单元测试覆盖率，文章先从 JaCoCo 的 Eclipse 插件 EclEmma 开始，直观地介绍了如何一步步提高单元测试质量，最终达到对代码的全覆盖；然后为大家介绍了如何将 JaCoCo 集成到 Ant 构建脚本中，生成漂亮的单元测试覆盖率报告。但是使用 JaCoCo 只是第一步，重要的是开发人员能够根据工具所给的反馈，不断改进自己的单元测试，写出高质量的代码。

参考资料

学习

from:http://www.ibm.com/developerworks/cn/java/j-lo-jacoco/index.html

 

Spring MVC 3 深入总结

JAVA, MVC

一、前言：

大家好，Spring3 MVC是非常优秀的MVC框架，由其是在3.0版本号公布后，如今有越来越多的团队选择了Spring3 MVC了。Spring3 MVC结构简单，应了那句话简单就是美，并且他强大不失灵活，性能也非常优秀。

官方的下载网址是：http://www.springsource.org/download   （本文使用是的Spring 3.0.5版本号）

 

Struts2也是比較优秀的MVC构架，长处非常多比方良好的结构。但这里想说的是缺点，Struts2因为採用了值栈、OGNL表达式、struts2标签库等，会导致应用的性能下降。Struts2的多层拦截器、多实例action性能都非常好。能够參考我写的一篇关于Spring MVC与Struts2与Servlet比較的文章 http://elf8848.iteye.com/admin/blogs/698217

 

Spring3 MVC的长处：

1、Spring3 MVC的学习难度小于Struts2，Struts2用不上的多余功能太多。呵呵，当然这不是决定因素。

2、Spring3 MVC非常easy就能够写出性能优秀的程序，Struts2要处处小心才干够写出性能优秀的程序（指MVC部分）

3、Spring3 MVC的灵活是你无法想像的，Spring的扩展性有口皆碑，Spring3 MVC当然也不会落后，不会因使用了MVC框架而感到有不论什么的限制。

 

Struts2的众多长处：略…   (呵呵，是不是不公平？)

 

众多文章开篇时总要吹些牛，吸引一下读者的眼球，把读者的胃口调起来，这样大家才有兴趣接着往后看。本文也没能例外。只是保证你看了之后不会懊悔定有收获。

 

 

二、核心类与接口：

 

先来了解一下，几个重要的接口与类。如今不知道他们是干什么的没关系，先混个脸熟，为以后认识他们打个基础。

 

DispatcherServlet   — 前置控制器

 

HandlerMapping接口 — 处理请求的映射

HandlerMapping接口的实现类：

SimpleUrlHandlerMapping  通过配置文件，把一个URL映射到Controller

DefaultAnnotationHandlerMapping  通过注解，把一个URL映射到Controller类上

 

HandlerAdapter接口 — 处理请求的映射

AnnotationMethodHandlerAdapter类，通过注解，把一个URL映射到Controller类的方法上

 

Controller接口 — 控制器

因为我们使用了@Controller注解，加入了@Controller注解注解的类就能够担任控制器（Action）的职责,

所以我们并没实用到这个接口。

 

 

 

HandlerInterceptor 接口–拦截器

无图，我们自己实现这个接口，来完毕拦截的器的工作。

 

 

ViewResolver接口的实现类

UrlBasedViewResolver类 通过配置文件，把一个视图名交给到一个View来处理

InternalResourceViewResolver类，比上面的类，增加了JSTL的支持

 

View接口

JstlView类

 

LocalResolver接口

 

HandlerExceptionResolver接口 –异常处理

SimpleMappingExceptionResolver实现类

 

 

ModelAndView类

无图。

 

 

 

 

 

三、核心流程图

 

本图是我个人画的，有不严谨的地方，大家对付看吧。总比没的看强。

 

 
四、DispatcherServlet说明

 

使用Spring MVC,配置DispatcherServlet是第一步。

DispatcherServlet是一个Servlet,所以能够配置多个DispatcherServlet。

DispatcherServlet是前置控制器，配置在web.xml文件里的。拦截匹配的请求，Servlet拦截匹配规则要自已定义，把拦截下来的请求，根据某某规则分发到目标Controller(我们写的Action)来处理。

 

“某某规则”：是依据你使用了哪个HandlerMapping接口的实现类的不同而不同。

 

先来看第一个样例：

Xml代码
  1. <web-app>
  2.     <servlet>
  3.         <servlet-name>example</servlet-name>
  4.         <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  5.         <load-on-startup>1</load-on-startup>
  6.     </servlet>
  7.     <servlet-mapping>
  8.         <servlet-name>example</servlet-name>
  9.         <url-pattern>*.form</url-pattern>
  10.     </servlet-mapping>
  11. </web-app>

<load-on-startup>1</load-on-startup>是启动顺序，让这个Servlet随Servletp容器一起启动。

<url-pattern>*.form</url-pattern> 会拦截*.form结尾的请求。

 

<servlet-name>example</servlet-name>这个Servlet的名字是example，能够有多个DispatcherServlet，是通过名字来区分的。每个DispatcherServlet有自己的WebApplicationContext上下文对象。同一时候保存的ServletContext中和Request对象中，关于key，以后说明。

 

在DispatcherServlet的初始化过程中，框架会在web应用的 WEB-INF目录下寻找名为[servlet-name]-servlet.xml 的配置文件，生成文件里定义的bean。

 

 

第二个样例：

Xml代码
  1. <servlet>
  2.     <servlet-name>springMVC</servlet-name>
  3.     <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  4.     <init-param>
  5.         <param-name>contextConfigLocation</param-name>
  6.         <param-value>classpath*:/springMVC.xml</param-value>
  7.     </init-param>
  8.     <load-on-startup>1</load-on-startup>
  9. </servlet>
  10. <servlet-mapping>
  11.     <servlet-name>springMVC</servlet-name>
  12.     <url-pattern>/</url-pattern>
  13. </servlet-mapping>

指明了配置文件的文件名称，不使用默认配置文件名称，而使用springMVC.xml配置文件。

当中<param-value>**.xml</param-value> 这里能够使用多种写法
1、不写,使用默认值:/WEB-INF/<servlet-name>-servlet.xml
2、<param-value>/WEB-INF/classes/springMVC.xml</param-value>
3、<param-value>classpath*:springMVC-mvc.xml</param-value>
4、多个值用逗号分隔
Servlet拦截匹配规则能够自已定义，Servlet拦截哪种URL合适？

当映射为@RequestMapping(“/user/add”)时：
1、拦截*.do，比如：/user/add.do，弊端：全部的url都要以.do结尾。不会影响訪问静态文件。
2、拦截/app/*，比如：/app/user/add，弊端：请求的url都要包括/app，@RequestMapping(“/user/add”)中不需要包括/app。
3、拦截/，比如：/user/add，弊端：对jpg,js,css静态文件的訪问也被拦截不能正常显示。后面有解决的方法。
4、拦截/*，能够走到Action中，但转发到jsp时再次被拦截，不能訪问到jsp。

 

 

五、双亲上下文的说明

 

假设你使用了listener监听器来载入配置，一般在Struts+Spring+Hibernate的项目中都是使用listener监听器的。例如以下

Java代码
  1. <listener>
  2.   <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  3. </listener>

Spring会创建一个全局的WebApplicationContext上下文，称为根上下文 ，保存在 ServletContext中，key是WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE属性的值。能够使用工具类取出上下文：WebApplicationContextUtils.getWebApplicationContext(ServletContext);

 

DispatcherServlet是一个Servlet,能够同一时候配置多个，每一个 DispatcherServlet有一个自己的 WebApplicationContext上下文，这个上下文继承了 根上下文 中全部东西。 保存在 ServletContext中，key是”org.springframework.web.servlet.FrameworkServlet.CONTEXT”+Servlet名称。当一个Request对象产生时，会把这个WebApplicationContext上下文保存在Request对象中，key是DispatcherServlet.class.getName() + “.CONTEXT”。能够使用工具类取出上下文：RequestContextUtils.getWebApplicationContext(request);

 

Spring中的 ApplicationContext实例能够被限制在不同的作用域（scope）中。
在web MVC框架中，每一个 DispatcherServlet有它自己的WebApplicationContext ，这个context继承了根 WebApplicationContext 的全部bean定义。
这些继承的bean也能够在每一个serlvet自己的所属的域中被覆盖（override），覆盖后的bean 能够被设置上仅仅有这个servlet实例自己使用的属性。

 

总结：不使用listener监听器来载入spring的配置，改用DispatcherServlet来载入spring的配置，不要双亲上下文，仅仅使用一个DispatcherServlet，事情就简单了，什么麻烦事儿也没有了。

 

 

六、springMVC-mvc.xml 配置文件片段解说 （未使用默认配置文件名称）

 

Xml代码
  1.    <!– 自己主动扫描的包名 –>
  2.    <context:component-scan base-package=”com.app,com.core,JUnit4″ ></context:component-scan>
  4.    <!– 默认的注解映射的支持 –>
  5.    <mvc:annotation-driven />
  7.    <!– 视图解释类 –>
  8.    <bean class=”org.springframework.web.servlet.view.InternalResourceViewResolver”>
  9.     <property name=”prefix” value=”/WEB-INF/jsp/”/>
  10.     <property name=”suffix” value=”.jsp”/><!–可为空,方便实现自已的根据扩展名来选择视图解释类的逻辑  –>
  11.     <property name=”viewClass” value=”org.springframework.web.servlet.view.JstlView” />
  12.    </bean>
  14. <!– 拦截器 –>
  15.    <mvc:interceptors>
  16.     <bean class=”com.core.mvc.MyInteceptor” />
  17. </mvc:interceptors>
  19.     <!– 对静态资源文件的訪问  方案一 （二选一） –>
  20.     <mvc:default-servlet-handler/>
  22.     <!– 对静态资源文件的訪问  方案二 （二选一）–>
  23. <mvc:resources mapping=”/images/**” location=”/images/” cache-period=”31556926″/>
  24. <mvc:resources mapping=”/js/**” location=”/js/” cache-period=”31556926″/>
  25. <mvc:resources mapping=”/css/**” location=”/css/” cache-period=”31556926″/>

 

<context:component-scan/> 扫描指定的包中的类上的注解，经常使用的注解有：

@Controller 声明Action组件
@Service    声明Service组件    @Service(“myMovieLister”)
@Repository 声明Dao组件
@Component   泛指组件, 当不好归类时.
@RequestMapping(“/menu”)  请求映射
@Resource  用于注入，( j2ee提供的 ) 默认按名称装配，@Resource(name=”beanName”)
@Autowired 用于注入，(srping提供的) 默认按类型装配
@Transactional( rollbackFor={Exception.class}) 事务管理
@ResponseBody
@Scope(“prototype”)   设定bean的作用域

 

<mvc:annotation-driven /> 是一种简写形式，全然能够手动配置替代这样的简写形式，简写形式能够让初学都高速应用默认配置方案。<mvc:annotation-driven /> 会自己主动注冊DefaultAnnotationHandlerMapping与AnnotationMethodHandlerAdapter 两个bean,是spring MVC为@Controllers分发请求所必须的。
并提供了：数据绑定支持，@NumberFormatannotation支持，@DateTimeFormat支持，@Valid支持，读写XML的支持（JAXB），读写JSON的支持（Jackson）。
后面，我们处理响应ajax请求时，就使用到了对json的支持。
后面，对action写JUnit单元測试时，要从spring IOC容器中取DefaultAnnotationHandlerMapping与AnnotationMethodHandlerAdapter 两个bean，来完毕測试，取的时候要知道是<mvc:annotation-driven />这一句注冊的这两个bean。

 

<mvc:interceptors/> 是一种简写形式。通过看前面的大图，知道，我们能够配置多个HandlerMapping。<mvc:interceptors/>会为每个HandlerMapping，注入一个拦截器。事实上我们也能够手动配置为每个HandlerMapping注入一个拦截器。

 

<mvc:default-servlet-handler/> 使用默认的Servlet来响应静态文件。

 

<mvc:resources mapping=”/images/**” location=”/images/” cache-period=”31556926″/> 匹配URL  /images/**  的URL被当做静态资源，由Spring读出到内存中再响应http。
七、怎样訪问到静态的文件，如jpg,js,css？

怎样你的DispatcherServlet拦截 *.do这种URL，就不存在訪问不到静态资源的问题。假设你的DispatcherServlet拦截“/”，拦截了全部的请求，同一时候对*.js,*.jpg的訪问也就被拦截了。

 

目的：能够正常訪问静态文件，不要找不到静态文件报404。

方案一：激活Tomcat的defaultServlet来处理静态文件

Xml代码
  1. <servlet-mapping>
  2.     <servlet-name>default</servlet-name>
  3.     <url-pattern>*.jpg</url-pattern>
  4. </servlet-mapping>
  5. <servlet-mapping>
  6.     <servlet-name>default</servlet-name>
  7.     <url-pattern>*.js</url-pattern>
  8. </servlet-mapping>
  9. <servlet-mapping>
  10.     <servlet-name>default</servlet-name>
  11.     <url-pattern>*.css</url-pattern>
  12. </servlet-mapping>
  13. 要配置多个，每种文件配置一个

要写在DispatcherServlet的前面， 让 defaultServlet先拦截，这个就不会进入Spring了，我想性能是最好的吧。

Tomcat, Jetty, JBoss, and GlassFish  默认 Servlet的名字 — “default”
Google App Engine 默认 Servlet的名字 — “_ah_default”
Resin 默认 Servlet的名字 — “resin-file”
WebLogic 默认 Servlet的名字  — “FileServlet”
WebSphere  默认 Servlet的名字 — “SimpleFileServlet”

 
方案二： 在spring3.0.4以后版本号提供了mvc:resources
mvc:resources 的用法：

Xml代码
  1. <!– 对静态资源文件的訪问 –>
  2. <mvc:resources mapping=”/images/**” location=”/images/” />

/images/**映射到ResourceHttpRequestHandler进行处理，location指定静态资源的位置.能够是web application根文件夹下、jar包里面，这样能够把静态资源压缩到jar包中。cache-period 能够使得静态资源进行web cache

假设出现以下的错误，可能是没有配置<mvc:annotation-driven />的原因。
报错WARNING: No mapping found for HTTP request with URI [/mvc/user/findUser/lisi/770] in DispatcherServlet with name ‘springMVC’

 

使用<mvc:resources/>元素,把mapping的URI注冊到SimpleUrlHandlerMapping的urlMap中,
key为mapping的URI pattern值,而value为ResourceHttpRequestHandler,
这样就巧妙的把对静态资源的訪问由HandlerMapping转到ResourceHttpRequestHandler处理并返回,所以就支持classpath文件夹,jar包内静态资源的訪问.
另外须要注意的一点是,不要对SimpleUrlHandlerMapping设置defaultHandler.由于对static uri的defaultHandler就是ResourceHttpRequestHandler,
否则无法处理static resources request.

 

 

方案三 ，使用<mvc:default-servlet-handler/>

 

Xml代码
  1. <mvc:default-servlet-handler/>

 

会把”/**” url,注冊到SimpleUrlHandlerMapping的urlMap中,把对静态资源的訪问由HandlerMapping转到org.springframework.web.servlet.resource.DefaultServletHttpRequestHandler处理并返回.
DefaultServletHttpRequestHandler使用就是各个Servlet容器自己的默认Servlet.

 

 

补充说明：多个HandlerMapping的运行顺序问题：

DefaultAnnotationHandlerMapping的order属性值是：0

< mvc:resources/ >自己主动注冊的 SimpleUrlHandlerMapping的order属性值是： 2147483646

 

<mvc:default-servlet-handler/>自己主动注冊 的SimpleUrlHandlerMapping 的order属性值是： 2147483647

 

spring会先运行order值比較小的。当訪问一个a.jpg图片文件时，先通过 DefaultAnnotationHandlerMapping 来找处理器，一定是找不到的，我们没有叫a.jpg的Action。再 按order值升序找，因为最后一个 SimpleUrlHandlerMapping 是匹配 “/**”的，所以一定会匹配上，再响应图片。

 

訪问一个图片，还要走层层匹配。真不知性能怎样？改天做一下压力測试，与Apache比一比。

 

最后再说明一下，怎样你的DispatcherServlet拦截 *.do这种URL，就不存上述问题了。

 
八、请求怎样映射到详细的Action中的方法？
方案一：基于xml配置映射，能够利用SimpleUrlHandlerMapping、BeanNameUrlHandlerMapping进行Url映射和拦截请求。
配置方法略。

方案二：基于注解映射，能够使用DefaultAnnotationHandlerMapping。

Xml代码
  1. <bean class=”org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping”>  </bean>

 

但前面我们配置了<mvc:annotation-driven />，他会自己主动注冊这个bean,就不需要我们显示的注冊这个bean了。
以上都能够注入interceptors，实现权限控制等前置工作。
我们使用第2种，基于注解来使用spring MVC

 

 

并在action类上使用：
@Controller
@RequestMapping(“/user”)

九、Spring中的拦截器：
Spring为我们提供了：
org.springframework.web.servlet.HandlerInterceptor接口，

org.springframework.web.servlet.handler.HandlerInterceptorAdapter适配器，
实现这个接口或继承此类，能够很方便的实现自己的拦截器。

有下面三个方法：

Action之前运行:
public boolean preHandle(HttpServletRequest request,
HttpServletResponse response, Object handler);

生成视图之前运行
public void postHandle(HttpServletRequest request,
HttpServletResponse response, Object handler,
ModelAndView modelAndView);

最后运行，可用于释放资源
public void afterCompletion(HttpServletRequest request,
HttpServletResponse response, Object handler, Exception ex)

分别实现预处理、后处理（调用了Service并返回ModelAndView，但未进行页面渲染）、返回处理（已经渲染了页面）
在preHandle中，能够进行编码、安全控制等处理；
在postHandle中，有机会改动ModelAndView；
在afterCompletion中，能够依据ex是否为null推断是否发生了异常，进行日志记录。
參数中的Object handler是下一个拦截器。

十、怎样使用拦截器？
自己定义一个拦截器，要实现HandlerInterceptor接口：

Java代码
  1. public class MyInteceptor implements HandlerInterceptor {
  2.     略。。。
  3. }

 

Spring MVC并没有总的拦截器，不能对全部的请求进行前后拦截。
Spring MVC的拦截器，是属于HandlerMapping级别的，能够有多个HandlerMapping ，每一个HandlerMapping能够有自己的拦截器。
当一个请求按Order值从小到大，顺序运行HandlerMapping接口的实现类时，哪一个先有返回，那就能够结束了，后面的HandlerMapping就不走了，本道工序就完毕了。就转到下一道工序了。
拦截器会在什么时候运行呢？ 一个请求交给一个HandlerMapping时，这个HandlerMapping先找有没有处理器来处理这个请求，怎样找到了，就运行拦截器，运行完拦截后，交给目标处理器。
假设没有找到处理器，那么这个拦截器就不会被运行。
在spring MVC的配置文件里配置有三种方法：
方案一，（近似）总拦截器，拦截全部url

Java代码
  1.    <mvc:interceptors>
  2.     <bean class=”com.app.mvc.MyInteceptor” />
  3. </mvc:interceptors>

为什么叫“近似”，前面说了，Spring没有总的拦截器。

<mvc:interceptors/>会为每一 个HandlerMapping，注入一个拦截器。总有一个HandlerMapping是能够找到处理器的，最多也仅仅找到一个处理器，所以这个拦截器总会被运行的。起到了总拦截器的作用。
方案二， （近似） 总拦截器， 拦截匹配的URL。

Xml代码
  1. <mvc:interceptors >
  2.   <mvc:interceptor>
  3.         <mvc:mapping path=”/user/*” /> <!– /user/*  –>
  4.         <bean class=”com.mvc.MyInteceptor”></bean>
  5.     </mvc:interceptor>
  6. </mvc:interceptors>

就是比 方案一多了一个URL匹配。

 

 

 

方案三,HandlerMappint上的拦截器

Xml代码
  1. <bean class=”org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping”>
  2.  <property name=”interceptors”>
  3.      <list>
  4.          <bean class=”com.mvc.MyInteceptor”></bean>
  5.      </list>
  6.  </property>
  7. </bean>

假设使用了<mvc:annotation-driven />， 它会自己主动注冊DefaultAnnotationHandlerMapping 与AnnotationMethodHandlerAdapter 这两个bean,所以就没有机会再给它注入interceptors属性，就无法指定拦截器。

当然我们能够通过人工配置上面的两个Bean，不使用 <mvc:annotation-driven />，就能够 给interceptors属性 注入拦截器了。

 

事实上我也不建议使用<mvc:annotation-driven />，而建议手动写配置文件，来替代 <mvc:annotation-driven />，这就控制力就强了。

 

 

 

 

十一、怎样实现全局的异常处理？

在spring MVC的配置文件里：

Xml代码
  1. <!– 总错误处理–>
  2. <bean id=”exceptionResolver” class=”org.springframework.web.servlet.handler.SimpleMappingExceptionResolver”>
  3.     <property name=”defaultErrorView”>
  4.         <value>/error/error</value>
  5.     </property>
  6.     <property name=”defaultStatusCode”>
  7.         <value>500</value>
  8.     </property>
  9. <property name=”warnLogCategory”>
  10.         <value>org.springframework.web.servlet.handler.SimpleMappingExceptionResolver</value>
  11.     </property>
  12. </bean>

 

这里基本的类是SimpleMappingExceptionResolver类，和他的父类AbstractHandlerExceptionResolver类。

详细能够配置哪些属性，我是通过查看源代码知道的。

你也能够实现HandlerExceptionResolver接口，写一个自己的异常处理程序。spring的扩展性是非常好的。

 

 

通过SimpleMappingExceptionResolver我们能够将不同的异常映射到不同的jsp页面（通过exceptionMappings属性的配置）。

 

同一时候我们也能够为全部的异常指定一个默认的异常提示页面（通过defaultErrorView属性的配置），假设所抛出的异常在exceptionMappings中没有相应的映射，则Spring将用此默认配置显示异常信息。

注意这里配置的异常显示界面均仅包含主文件名称，至于文件路径和后缀已经在viewResolver中指定。如/error/error表示/error/error.jsp

 

 

显示错误的jsp页面：

Html代码
  1. <%@ page language=”java” contentType=”text/html; charset=GBK”
  2.     pageEncoding=”GBK”%>
  3. <%@ page import=”java.lang.Exception”%>
  4. <!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>
  5. <html>
  6. <head>
  7. <meta http-equiv=”Content-Type” content=”text/html; charset=GBK”>
  8. <title>错误页面</title>
  9. </head>
  10. <body>
  11. <h1>出错了</h1>
  12. <%
  13. Exception e = (Exception)request.getAttribute(“exception”);
  14. out.print(e.getMessage());
  15. %>
  16. </body>
  17. </html>

当中一句：request.getAttribute(“exception”)，key是exception，也是在SimpleMappingExceptionResolver类默认指定的，是可能通过配置文件改动这个值的，大家能够去看源代码。

 

參考文章：

http://www.blogjava.net/wuxufeng8080/articles/191150.html

http://fangjunai.blog.163.com/blog/static/1124970520108102013839/

 

 

 

十二、怎样把全局异常记录到日志中？

在前的配置中，当中有一个属性warnLogCategory，值是“SimpleMappingExceptionResolver类的全限定名”。我是在SimpleMappingExceptionResolver类父类AbstractHandlerExceptionResolver类中找到这个属性的。查看源代码后得知：假设warnLogCategory不为空，spring就会使用apache的org.apache.commons.logging.Log日志工具，记录这个异常，级别是warn。

值：“org.springframework.web.servlet.handler.SimpleMappingExceptionResolver”，是“SimpleMappingExceptionResolver类的全限定名”。这个值不是随便写的。  由于我在log4j的配置文件里还要增加log4j.logger.org.springframework.web.servlet.handler.SimpleMappingExceptionResolver=WARN，保证这个级别是warn的日志一定会被记录，即使log4j的根日志级别是ERROR。

 

 

 

 

十三、怎样给spring3 MVC中的Action做JUnit单元測试？

使用了spring3 MVC后，给action做单元測试也非常方便，我曾经从来不给action写单元測试的，再在不同了，方便了，所以一定要写。

 

JUnitActionBase类是全部JUnit的測试类的父类

 

Java代码
  1. package test;
  2. import javax.servlet.http.HttpServletRequest;
  3. import javax.servlet.http.HttpServletResponse;
  4. import org.junit.BeforeClass;
  5. import org.springframework.mock.web.MockServletContext;
  6. import org.springframework.web.context.WebApplicationContext;
  7. import org.springframework.web.context.support.XmlWebApplicationContext;
  8. import org.springframework.web.servlet.HandlerAdapter;
  9. import org.springframework.web.servlet.HandlerExecutionChain;
  10. import org.springframework.web.servlet.HandlerMapping;
  11. import org.springframework.web.servlet.ModelAndView;
  12. import org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter;
  13. import org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping;
  14. /**
  15. * 说明： JUnit測试action时使用的基类
  16. *
  17. * @author  赵磊
  18. * @version 创建时间：2011-2-2 下午10:27:03
  19. */
  20. public class JUnitActionBase {
  21.     private static HandlerMapping handlerMapping;
  22.     private static HandlerAdapter handlerAdapter;
  23.     /**
  24.      * 读取spring3 MVC配置文件
  25.      */
  26.     @BeforeClass
  27.  public static void setUp() {
  28.         if (handlerMapping == null) {
  29.             String[] configs = { “file:src/springConfig/springMVC.xml” };
  30.             XmlWebApplicationContext context = new XmlWebApplicationContext();
  31.             context.setConfigLocations(configs);
  32.             MockServletContext msc = new MockServletContext();
  33.             context.setServletContext(msc);         context.refresh();
  34.             msc.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, context);
  35.             handlerMapping = (HandlerMapping) context
  36.                     .getBean(DefaultAnnotationHandlerMapping.class);
  37.             handlerAdapter = (HandlerAdapter) context.getBean(context.getBeanNamesForType(AnnotationMethodHandlerAdapter.class)[0]);
  38.         }
  39.     }
  41.     /**
  42.      * 运行request对象请求的action
  43.      *
  44.      * @param request
  45.      * @param response
  46.      * @return
  47.      * @throws Exception
  48.      */
  49.     public ModelAndView excuteAction(HttpServletRequest request, HttpServletResponse response)
  50.  throws Exception {
  51.         HandlerExecutionChain chain = handlerMapping.getHandler(request);
  52.         final ModelAndView model = handlerAdapter.handle(request, response,
  53.                 chain.getHandler());
  54.         return model;
  55.     }
  56. }

 

 

 

 

 

 

这是个JUnit測试类，我们能够new Request对象，来參与測试，太方便了。给request指定訪问的URL，就能够请求目标Action了。

 

Java代码
  1. package test.com.app.user;
  2. import org.junit.Assert;
  3. import org.junit.Test;
  4. import org.springframework.mock.web.MockHttpServletRequest;
  5. import org.springframework.mock.web.MockHttpServletResponse;
  6. import org.springframework.web.servlet.ModelAndView;
  8. import test.JUnitActionBase;
  10. /**
  11. * 说明： 測试OrderAction的样例
  12. *
  13. * @author  赵磊
  14. * @version 创建时间：2011-2-2 下午10:26:55
  15. */
  17. public class TestOrderAction extends JUnitActionBase {
  18.     @Test
  19.     public void testAdd() throws Exception {
  20.     MockHttpServletRequest request = new MockHttpServletRequest();
  21.         MockHttpServletResponse response = new MockHttpServletResponse();
  22.         request.setRequestURI(“/order/add”);
  23.         request.addParameter(“id”, “1002”);
  24.         request.addParameter(“date”, “2010-12-30”);
  25.         request.setMethod(“POST”);
  26.         // 运行URI相应的action
  27.         final ModelAndView mav = this.excuteAction(request, response);
  28.         // Assert logic
  29.         Assert.assertEquals(“order/add”, mav.getViewName());
  30.         String msg=(String)request.getAttribute(“msg”);
  31.         System.out.println(msg);
  32.     }
  33. }

须要说明一下 ：由于当前最想版本号的Spring(Test) 3.0.5还不支持@ContextConfiguration的注解式context file注入，所以还须要写个setUp处理下，否则类似于Tiles的载入过程会有错误，由于没有ServletContext。3.1的版本号应该有更好的解决方式，參见： https://jira.springsource.org/browse/SPR-5243 。

參考 ：http://www.iteye.com/topic/828513

 

 

 

 

十四、转发与重定向

能够通过redirect/forward:url方式转到还有一个Action进行连续的处理。

能够通过redirect:url 防止表单反复提交 。

写法例如以下：

return “forward:/order/add”;

return “redirect:/index.jsp”;

 

 

 

 

 十五、处理ajax请求

 

1、引入以下两个jar包，我用的是1.7.2，好像1.4.2版本号以上都能够，下载地址： http://wiki.fasterxml.com/JacksonDownload

jackson-core-asl-1.7.2.jar

jackson-mapper-asl-1.7.2.jar

 

2、spring的配置文件里要有这一行，才干使用到spring内置支持的json转换。假设你手工把POJO转成json就能够不需要使用spring内置支持的json转换。

<mvc:annotation-driven />

 

3、使用@ResponseBody注解

Java代码
  1. /**
  2.  * ajax測试
  3. * http://127.0.0.1/mvc/order/ajax
  4.  */
  6. @RequestMapping(“/ajax”)
  7. @ResponseBody
  8. public Object ajax(HttpServletRequest request){
  9.     List<String> list=new ArrayList<String>();
  10.     list.add(“电视”);
  11. nbsp;       list.add(“洗衣机”);
  12.     list.add(“冰箱”);
  13.     list.add(“电脑”);
  14.     list.add(“汽车”);
  15.     list.add(“空调”);
  16.     list.add(“自行车”);
  17.     list.add(“饮水机”);
  18.     list.add(“热水器”);
  19.     return list;
  20. }

from:http://www.cnblogs.com/lcchuguo/p/4052521.html?utm_source=tuicool&utm_medium=referral