使用正则表达式验证进行验证

只能输入数字：“^[0-9]*$”
只能输入n位的数字：“^d{n}$”
只能输入至少n位数字：“^d{n,}$”
只能输入m-n位的数字：“^d{m,n}$”
只能输入零和非零开头的数字：“^(0|[1-9][0-9]*)$”
只能输入有两位小数的正实数：“^[0-9]+(.[0-9]{2})?$”
只能输入有1-3位小数的正实数：“^[0-9]+(.[0-9]{1,3})?$”
只能输入非零的正整数：“^+?[1-9][0-9]*$”
只能输入非零的负整数：“^-[1-9][0-9]*$”
只能输入长度为3的字符：“^.{3}$”
只能输入由26个英文字母组成的字符串：“^[A-Za-z]+$”
只能输入由26个大写英文字母组成的字符串：“^[A-Z]+$”
只能输入由26个小写英文字母组成的字符串：“^[a-z]+$”
只能输入由数字和26个英文字母组成的字符串：“^[A-Za-z0-9]+$”
只能输入由数字、26个英文字母或者下划线组成的字符串：“^w+$”
验证用户密码:“^[a-zA-Z]w{5,17}$”正确格式为：以字母开头，长度在6-18之间，

只能包含字符、数字和下划线。
验证是否含有^%&',;=?$"等字符：“[^%&',;=?$x22]+”
只能输入汉字：“^[u4e00-u9fa5],{0,}$”
验证Email地址："^[^@]([a-zA-Z_0-9.])+@([a-zA-Z_0-9.])+[^@]$"
验证InternetURL：“^http://([w-]+.)+[w-]+(/[w-./?%&=]*)?$”

验证电话号码：“^((d{3,4})|d{3,4}-)?d{7,8}$”

asp.net里面自带的验证Email地址：\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*

只能输入数字与符号“-”　^[\d\-]+$

只能输入数字、英文、下划线、中杠线 [\w\-]+

Struts2拦截器中操作Action

public String intercept(ActionInvocation invoker) throws Exception {

ActionContext ctx = invoker.getInvocationContext();
Object action = invoker.getAction();
String actionStr = action.toString();

//取得request和response 对象
HttpServletRequest request = ServletActionContext.getRequest();
HttpServletResponse response = ServletActionContext.getResponse();

//取得当前URL
Enumeration qnames= request.getParameterNames();
String qstring="";
while(qnames.hasMoreElements()){
String qname=(String)qnames.nextElement();
String[] qvalues=request.getParameterValues(qname);
for(int j= 0;j< qvalues.length;j++){
if(!qnames.hasMoreElements()&&j==qvalues.length-1){
qstring=qstring+java.net.URLEncoder.encode(qname)+"="+java.net.URLEncoder.encode(qvalues[j]);
}else{
qstring=qstring+java.net.URLEncoder.encode(qname)+"="+java.net.URLEncoder.encode(qvalues[j])+"&";
}

}
}
String referer= request.getHeader("Referer");
String refurl = null;
if(!CommonUtil.isInvalid(referer)&&referer.endsWith(".do")){
refurl= referer;
}else{
if(CommonUtil.isInvalid(qstring)){
refurl= referer;
}else{
refurl= referer+"&"+qstring;
}
}
System.out.println("##################################refurl="+refurl);

//取得当前Action名
String name = invoker.getInvocationContext().getName();
//取得当前namespace
String namespace = invoker.getProxy().getNamespace();
if ((namespace != null) && (namespace.trim().length() > 0)) {
if ("/".equals(namespace.trim())) {
} else {
namespace += "/";
}
}
//取得当前URL
String URL = namespace + invoker.getProxy().getActionName();
URL += ".do";

//遍历request中getParameter中所有参数
Map parameterMap = request.getParameterMap();
Iterator iter = parameterMap.entrySet().iterator();

while (iter.hasNext()) {
Map.Entry entry = (Map.Entry) iter.next();
String key = (String)entry.getKey();
String value = (String)request.getParameter(key);
//System.out.println("#############"+key+"="+request.getParameter(key));
if(!StringOperateUtil.urlRewriteCheck(key, value)){
return "urlRewrite";
}
}

}

Spring三种注入IOC注入方式

1.Type1 接口注入
我们常常借助接口来将调用者与实现者分离。如:
public class ClassA {
private InterfaceB clzB;
public doSomething() {
Ojbect obj =
Class.forName(Config.BImplementation).newInstance();
clzB = (InterfaceB)obj;
clzB.doIt();
}
……
}
上面的代码中，ClassA依赖于InterfaceB的实现，如何获得InterfaceB实现类的实例？传统的方法是在
代码中创建InterfaceB实现类的实例，并将起赋予clzB。
而这样一来，ClassA在编译期即依赖于InterfaceB的实现。为了将调用者与实现者在编译期分离，于是有
了上面的代码，我们根据预先在配置文件中设定的实现类的类名(Config.BImplementation)，动态
加载实现类，并通过InterfaceB强制转型后为ClassA所用。这就是接口注入的一个最原始的雏形。
而对于一个Type1型IOC容器而言，加载接口实现并创建其实例的工作由容器完成。
如下面这个类:
public class ClassA {
private InterfaceB clzB;
public Object doSomething(InterfaceB b) {
clzB = b;
return clzB.doIt();
}
……
}
在运行期，InterfaceB实例将由容器提供。
Type1型IOC发展较早（有意或无意），在实际中得到了普遍应用，即使在IOC的概念尚未确立时，这样的
方法也已经频繁出现在我们的代码中。
下面的代码大家应该非常熟悉：
public class MyServlet extends HttpServlet {
public void doGet(
HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
……
}
}
这也是一个Type1 型注入，HttpServletRequest和HttpServletResponse实例由Servlet Container
在运行期动态注入。
另，Apache Avalon是一个较为典型的Type1型IOC容器。

2.Type2 设值注入
在各种类型的依赖注入模式中，设值注入模式在实际开发中得到了最广泛的应用（其中很大一部分得
力于Spring框架的影响）。
在笔者看来，基于设置模式的依赖注入机制更加直观、也更加自然。Quick Start中的示例，就是典
型的设置注入，即通过类的setter方法完成依赖关系的设置。


3.Type3 构造子注入
public class DIByConstructor {
private final DataSource dataSource;
private final String message;
public DIByConstructor(DataSource ds, String msg) {
this.dataSource = ds;
this.message = msg;
}
……
}
构造子注入，即通过构造函数完成依赖关系的设定，如：
可以看到，在Type3类型的依赖注入机制中，依赖关系是通过类构造函数建立，容器通过调用类的构
造方法，将其所需的依赖关系注入其中。
PicoContainer（另一种实现了依赖注入模式的轻量级容器）首先实现了Type3类型的依赖注入模式。


几种依赖注入模式的对比总结
接口注入模式因为历史较为悠久，在很多容器中都已经得到应用。但由于其在灵活性、易用性上不如
其他两种注入模式，因而在IOC的专题世界内并不被看好。
Type2和Type3型的依赖注入实现则是目前主流的IOC实现模式。这两种实现方式各有特点，也各具
优势（一句经典废话J）。

Type2 设值注入的优势
1． 对于习惯了传统JavaBean开发的程序员而言，通过setter方法设定依赖关系显得更加直
观，更加自然。
2． 如果依赖关系（或继承关系）较为复杂，那么Type3模式的构造函数也会相当庞大（我们需
要在构造函数中设定所有依赖关系），此时Type2模式往往更为简洁。
3． 对于某些第三方类库而言，可能要求我们的组件必须提供一个默认的构造函数（如Struts
中的Action），此时Type3类型的依赖注入机制就体现出其局限性，难以完成我们期望的功
能。

Type3 构造子注入的优势：
1． “在构造期即创建一个完整、合法的对象”，对于这条Java设计原则，Type3无疑是最好的
响应者。
2． 避免了繁琐的setter方法的编写，所有依赖关系均在构造函数中设定，依赖关系集中呈现，
更加易读。
3． 由于没有setter方法，依赖关系在构造时由容器一次性设定，因此组件在被创建之后即处于
相对“不变”的稳定状态，无需担心上层代码在调用过程中执行setter方法对组件依赖关系
产生破坏，特别是对于Singleton模式的组件而言，这可能对整个系统产生重大的影响。
4． 同样，由于关联关系仅在构造函数中表达，只有组件创建者需要关心组件内部的依赖关系。
对调用者而言，组件中的依赖关系处于黑盒之中。对上层屏蔽不必要的信息，也为系统的
层次清晰性提供了保证。
5． 通过构造子注入，意味着我们可以在构造函数中决定依赖关系的注入顺序，对于一个大量
依赖外部服务的组件而言，依赖关系的获得顺序可能非常重要，比如某个依赖关系注入的
先决条件是组件的DataSource及相关资源已经被设定。

tomcat 的jvm 内存溢出问题的解决

tomcat 的jvm 内存溢出问题的解决

最近在熟悉一个开发了有几年的项目，需要把数据库从mysql移植到oracle，首先把jdbc的连接指向mysql，打包放到tomcat里面，可以跑起来，没有问题，可是当把jdbc连接指向oracle的时候，tomcat就连续抛java.lang.OutOfMemoryError的错误，上网 google了一下，了解了一下tomcat的运行机制，也解决了问题，share出来，以备查。

1、首先是：java.lang.OutOfMemoryError: Java heap space

解释：

Heap size 设置

JVM 堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。
提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。

解决方法：

手动设置Heap size
修改TOMCAT_HOME/bin/catalina.bat，在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：

Java代码
set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m
set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m


或修改catalina.sh
在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
JAVA_OPTS="$JAVA_OPTS -server -Xms800m -Xmx800m -XX:MaxNewSize=256m"

2、其次是：java.lang.OutOfMemoryError: PermGen space

原因：

PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。

解决方法：

1. 手动设置MaxPermSize大小
修改TOMCAT_HOME/bin/catalina.bat（Linux下为catalina.sh），在
Java代码
“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m
“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m


catalina.sh下为：

Java代码
JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m"
JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m"



另外看到了另外一个帖子，觉得挺好，摘抄如下：
分析java.lang.OutOfMemoryError: PermGen space

发现很多人把问题归因于： spring,hibernate,tomcat，因为他们动态产生类,导致JVM中的permanent heap溢出。然后解决方法众说纷纭，有人说升级 tomcat版本到最新甚至干脆不用tomcat。还有人怀疑spring的问题，在spring论坛上讨论很激烈，因为spring在AOP时使用 CBLIB会动态产生很多类。

但问题是为什么这些王牌的开源会出现同一个问题呢，那么是不是更基础的原因呢？tomcat在Q&A很隐晦的回答了这一点，我们知道这个问题，但这个问题是由一个更基础的问题产生。

于是有人对更基础的JVM做了检查，发现了问题的关键。原来SUN 的JVM把内存分了不同的区，其中一个就是permenter区用来存放用得非常多的类和类描述。本来SUN设计的时候认为这个区域在JVM启动的时候就固定了，但他没有想到现在动态会用得这么广泛。而且这个区域有特殊的垃圾收回机制，现在的问题是动态加载类到这个区域后，gc根本没办法回收！


对于以上两个问题，我的处理是：

在catalina.bat的第一行增加：

Java代码
set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m
set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m


在catalina.sh的第一行增加：

Java代码
JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m

struts2拦截器概述

struts2拦截器概述

Struts2的拦截器和Servlet过滤器类似。在执行Action的execute方法之前，Struts2会首先执行在struts.xml中引用的拦截器，在执行完所有引用的拦截器的intercept方法后，会执行Action的execute方法。

Struts2拦截器类必须从com.opensymphony.xwork2.interceptor.Interceptor接口继承，在Intercepter接口中有如下三个方法需要实现：
void destroy();
void init();
String intercept(ActionInvocation invocation) throws Exception;

其中 intercept方法是拦截器的核心方法，所有安装的拦截器都会调用这个方法。在Struts2中已经在struts-default.xml中预定义了一些自带的拦截器，如timer、params等。如果在标签中继承struts-default，则当前 package就会自动拥有struts-default.xml中的所有配置。代码如下：

...
在struts-default.xml中有一个默认的引用，在默认情况下（也就是中未引用拦截器时）会自动引用一些拦截器。这个默认的拦截器引用如下：




















dojo\..*



input,back,cancel,browse


input,back,cancel,browse



上面在defaultStack中引用的拦截器都可以在中不经过引用就可以使用（如果在中引用了任何拦截器后，要使用在defaultStack中定义的拦截器，也需要在中重新引用，在后面将详细讲解）。

下面我们来看几个简单的拦截器的使用方法。

一、记录拦截器和execute方法的执行时间(timer)
???? timer是Struts2中最简单的拦截器，这个拦截器对应的类是com.opensymphony.xwork2.interceptor.TimerInterceptor。它的功能是记录execute方法和其他拦截器（在timer后面定义的拦截器）的intercept方法执行的时间总和。如下面的配置代码所示：






由于在timer后面没有其他的拦截器定义，因此，timer只能记录execute方法的执行时间，在访问first动作时，会在控制台输出类似下面的一条信息：

信息: Executed action [/test/first!execute] took 16 ms.

在使用timer拦截器时，需要commons-logging.jar的支持。将logger引用放到timer的后面，就可以记录logger拦截器的intercept方法和Action的execute方法的执行时间总和，代码如下：

????





大家可以使用如下的Action类来测试一下timer拦截器：

package action;

import com.opensymphony.xwork2.ActionSupport;

public class FirstAction extends ActionSupport

{
public String execute() throws Exception

{
Thread.sleep(1000); // 延迟1秒
return null;
}

}

如果只记录execute方法的执行时间，一般会输出如下的信息：

信息: Executed action [/test/first!execute] took 1000 ms.

二、通过请求调用Action的setter方法(params)

当客户端的一个form向服务端提交请求时，如有一个textfield，代码如下：






在提交后，Struts2将会自动调用first动作类中的setName方法，并将name文本框中的值通过setName方法的参数传入。实际上，这个操作是由params拦截器完成的，params对应的类是com.opensymphony.xwork2.interceptor.ParametersInterceptor。由于params已经在defaultStack中定义，因此，在未引用拦截器的中是会自动引用params的，如下面的配置代码，在访问first动作时，Struts2是会自动执行相应的setter方法的。



... ...



但如果在中引用了其他的拦截器，就必须再次引用params拦截器，Struts2才能调用相应的setter方法。如下面的配置代码所示：






三、通过配置参数调用Action的setter方法(static-params)
static-params拦截器可以通过配置标签来调用Action类的相应的setter方法，static-params拦截器对应的类是com.opensymphony.xwork2.interceptor.StaticParametersInterceptor。
下面配置代码演示了如何使用static-params拦截器：




比尔




如果first动作使用上面的配置，在访问first动作时，Struts2会自动调用setWho方法将“比尔”作为参数值传入setWho方法。

四、使用拦截器栈
为了能在多个动作中方便地引用同一个或几个拦截器，可以使用拦截器栈将这些拦截器作为一个整体来引用。拦截器栈要在标签中使用和子标签来定义。代码如下：











比尔




可以象使用拦截器一样使用拦截器栈，如上面代码所示。



public class AuthorityInterceptor extends AbstractInterceptor {
private static final long serialVersionUID = 1358600090729208361L;

//拦截Action处理的拦截方法
public String intercept(ActionInvocation invocation) throws Exception {
// 取得请求相关的ActionContext实例
ActionContext ctx=invocation.getInvocationContext();
Map session=ctx.getSession();
//取出名为user的session属性
String user=(String)session.get("user");
//如果没有登陆，或者登陆所有的用户名不是aumy，都返回重新登陆
if(user!=null && user.equals("aumy")){
return invocation.invoke();
}
//没有登陆，将服务器提示设置成一个HttpServletRequest属性
ctx.put("tip","您还没有登录，请登陆系统");
return Action.LOGIN;
}
}


"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd">





/login.jsp
/error.jsp
/welcome.jsp


/qurey.jsp








class="com.aumy.struts.example.intercepter.AuthorityInterceptor"
name="authority"/>












/login.jsp


method="show">
/show.jsp


method="add">
/add.jsp

struts2 重复提交拦截器用法 token与token-session

首先要在jsp的from标签里加入防重复提交标签， 生成如下的内容：(struts.token.name 标识哪个隐藏域存了 token 值)


注意自定义的表单域别重名了。它的作用是防止表单重复提交，每次加载页面 struts.token 的值都不一样，如果两次提交时该值一样，则认为是重复提交。此时要启用 TokenInterceptor(token) 拦截器，最好是也启用 TokenSessionStoreInterceptor(token-session) 拦截器，不然后台会出现错误提示：

2008-11-17 20:39:21 com.opensymphony.xwork2.interceptor.ParametersInterceptor setParameters
严重: ParametersInterceptor - [setParameters]: Unexpected Exception catched: Error setting expression 'struts.token' with value '[Ljava.lang.String;@1c2e163'
2008-11-17 20:39:21 com.opensymphony.xwork2.interceptor.ParametersInterceptor setParameters
严重: ParametersInterceptor - [setParameters]: Unexpected Exception catched: Error setting expression 'struts.token.name' with value '[Ljava.lang.String;@abaf8c'

但不影响使用。不过如果只有 token-session 拦截器却是不行的。

token 和 token-session 拦截器的启用，是在 struts.xml 配置文件中，既可以为包启用，也可以单独为某个 action 启用：

1) 为包启用 token 和 token-session











/login.jsp
/exception.jsp

............................................................................

2) 为 Action 启用 token 和 token-session





/login.jsp
/exception.jsp


............................................................................


注意 token、token-session 和 defaultStack 的顺序要保证，还需要加上名为 "invalid.token" 的 result，当发现重复提交时转向到这个逻辑页，如 /exception.jsp，在 /exception.jsp 加上 在出现重复提交时就会提示：The form has already been processed or no token was supplied, please try again.


token: 在活动中检查合法令牌(token), 防止表单的重复提交;
token-session: 同上, 但是在接到非法令牌时将提交的数据保存在session中;