公元2008年6月23日,终于从大学毕业了.

    JAVAEYE是一个技术性的网站,都好久没有上来看看了.前段时间都忙着毕业的事情,现在一切都又归于平静,好像就没有经历过一样.现在写的东西和技术一点也没有粘边,也算是我在JAVAEYE上发表的一个海阔天空吧.
    大学四年,说真的,学到的东西不多,而丢掉的东西比学到的还多.回首过去,好像我就没有在大学里呆过一样.短短的四年,如过眼云烟,慢慢地散去.大一时迷茫,一天到黑的打游戏;大二时沉轮,天天都在帮别人打游戏;直到大三时,才开始接触到程序性的东西,开始学习写程序,接触java;大四,在公司实习了一年,慢慢地接触外面的时候.四年,就这么四句话,简单地接触,又简单的回忆.川农,就像一个昨天的回忆,慢慢地消逝了.
    昨天上午开始发放毕业证,下午就到了成都,开始自己的工作人生.本来说星期天就回公司的,却不想又耽误了一天.回到成都,把自己的一身学生味全部洗掉,告诉自己,现在自己已经不再是学生了,自己是一个社会上为自己打拼的上班族.在现在的公司已经呆了有一年了吧,也不是说很满意现在公司的发展情况,但终要为自己的现在和将来考虑.慢慢地为自己的未来作打算,做好自己现在的工作.
    我的那些同学们,不知道在以后的日子中是否将你们忘去,或许是因为我就是一个人生中的过客,在存在的时候会让人想起,当没有任何有意义的事情时又会被人忘却.我是无所谓的,大学毕业时发的留言册,我一页也没有去打开过,也没有为别的人打开过.我始终相信,那些纸上的记录,始终比不过在心里面记起的那些人.如果你没有把我忘记,无论什么时候,当你想起我,我始终都会在你想起的那个地方.昨天临走时,也没有跟很多的人打招呼,几个熟悉的人将行李装在车上,简短的告别,就匆匆地上路了.可能是许久的在成都呆久了,没有太多的离愁别绪,我甚至以为,可能过几天,我还会回到雅安,回到我们的学校.或许,我没有来到雅安,那只是昨天的记忆,我为着明天的事情忙碌,记不清太多的过去.
    关于爱情,在大学里,我是失败的.虽然始终认为在大学里寻找一份纯真的爱情对我来说是很重要的事情.然而我去没有把它实现过.也许就是我个人的不能相处,还是自己本身就是一个学生,负担不起别人对自己的期望.前天晚上,和她一起去唱歌,唱到12点过.把嗓子都唱破了,最后却不知道应该说什么.我知道,她不会跟着我走,因为她已经是她家乡学校的研究生了.真地放不下她,从理性的角度看,她真的是一个很好的新娘,是一个很好的和自己走过一生的女子.然而我去没有把她拉回自己的身边.她有她心目中的王子,她有她的憧憬,然而却不想再记得我.我想我会努力,就像对待自己的未来一样.我会努力,至少不只是对她,我想找一个很好的女子,但不是现在.如果她愿意跟我走,我不会再有寄托,然而她走了.仍然不会有寄托,因为她走了,我不确定未来与我相遇的人究竟是什么样的,也不知道那个人与自己是否能够很好的相处.但现在,我已经不再想起那些儿女情长的事了.也许是因为现在的自己不再适合去谈情说爱,还是因为我需要一段时间来好好对以后的她有一个详细的说明.我要终止那些事,让那些事在三年之后再说吧.
    匆匆地毕业了.为了一份学士证书,我在大学里混了四年.为了未来,我可能会在社会里奋斗一生.我的朋友们,如果哪天记得我,请想得一起走过的日子.

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

在前一篇中<struts2与json插件(1)> ,讲到了解决在struts2中出现的一点点乱码问题,就想看看json中的数据处理方式.由struts2的处理流程来看,主要处理result的代码如下在defaultActionInvocation中:

private void executeResult() throws Exception {
        result = createResult();

        String timerKey = "executeResult: "+getResultCode();
        try {
            UtilTimerStack.push(timerKey);
            if (result != null) {
                result.execute(this);
            } else if (resultCode != null && !Action.NONE.equals(resultCode)) {
                throw new ConfigurationException("No result defined for action " + getAction().getClass().getName() 
                        + " and result " + getResultCode(), proxy.getConfig());
            } else {
                if (LOG.isDebugEnabled()) {
                    LOG.debug("No result returned for action "+getAction().getClass().getName()+" at "+proxy.getConfig().getLocation());
                }
            }
        } finally {
            UtilTimerStack.pop(timerKey);
        }
    }

 
如上所示,result就是返回的result,而resultCode就是我们通用的String返回类型了.而json插件中,采用默认值Action.Success来得到json类型,而在result中处理,即调用上面的result.invoke(this).json中的主要处理代码如下(省略中间一些代码):

    public void execute(ActionInvocation invocation) throws Exception {
        ActionContext actionContext = invocation.getInvocationContext();
        HttpServletRequest request = (HttpServletRequest) actionContext
            .get(StrutsStatics.HTTP_REQUEST);
        HttpServletResponse response = (HttpServletResponse) actionContext
            .get(StrutsStatics.HTTP_RESPONSE);

        try {
            String json;
            Object rootObject;
            if (this.enableSMD) {
                //generate SMD
                rootObject = this.writeSMD(invocation);
            } else {
                // generate JSON
                if (this.root != null) {
                    ValueStack stack = invocation.getStack();
                    rootObject = stack.findValue(this.root);
                } else {
                    rootObject = invocation.getAction();
                }
            }
            json = JSONUtil
                .serialize(rootObject, this.excludeProperties, ignoreHierarchy, enumAsBean);

            boolean writeGzip = enableGZIP && JSONUtil.isGzipInRequest(request);
           
            JSONUtil.writeJSONToResponse(response, this.defaultEncoding,
                isWrapWithComments(), json, false, writeGzip);

        } catch (IOException exception) {
            log.error(exception);
            throw exception;
        }
    }

可以看出,json插件的功能(在处理json上),就是将invocation中的action对象转化成json对象,再输出到页面上.
    在上面的应用上来看,用json插件必须注册json的resultType,而且,返回类型一定是json,也就是说,你必须给每一个json调用定义一个json的返回类型,而实际上这个类型就是转向jsonResult上,和一般的调用不一样,它不返回任何视图.即json这个返回类型感觉上完全是多余的,除了标明是json返回之外没有其他作用.而且对于解析来说,它是解析一个action对象,所就是说,如果你的action是富对象,里面有很多的属性,而实际你需要的不多时,那这个解析就完全失去了作用了.
     话说这么多,改进方法,从根本上来说,就是改进这种解析机制.是不解析当前的action对象,而是像spring一样,解析只需要解析的对象一样.如返回a,就只需要解析a.查看上面的executeResult()方法,其中对result和resultCode进行了处理.其中有这么一句

if (result != null) {
                result.execute(this);
            } else if (resultCode != null && !Action.NONE.equals(resultCode)) {
                throw new ConfigurationException("No result defined for action " + getAction().getClass().getName() 
                        + " and result " + getResultCode(), proxy.getConfig());
            } else {
                if (LOG.isDebugEnabled()) {
                    LOG.debug("No result returned for action "+getAction().getClass().getName()+" at "+proxy.getConfig().getLocation());
                }
            }

第一句,也就是一般我们进行处理的地方,调用result进行最后的处理.而第二句,则是对resultCode进行判断,而第三句什么都不做.所以,对于其他的处理,可以从resultCode下手.方法有两种,一是返回无类型,即void类型,二是返回Action.NONE.当是这两种类型的时候,struts2就不会对result进行主动处理了.详细可参见struts2对Action.NONE的说明,如下:

/**
     * The action execution was successful but do not
     * show a view. This is useful for actions that are
     * handling the view in another fashion like redirect.
     */
    public static final String NONE = "none";

 即我们只需要在action方法中,处理ajax调用,而返回void或者"none"就行了.参考方法调用就如下:

public void showCategoryListAjax2() throws Exception {
		this.category = this.service.getCategory(this.id);
		/** 如果该类别为空 **/
		if(this.category == null) {
			AjaxResponse.sendAjaxText(null, ServletActionContext.getResponse());
			return;
		}

		this.categoryList = this.service.getCategoryListBySuperCategory(this.category);

		AjaxResponse.sendAjaxText(this.categoryList, ServletActionContext.getResponse());
	}

 上面的返回类别是一种取巧的方法,更好的方法是返回Action.NONE.这样在struts.xml配置就像这样:

<action name="taa" class="articleAction" method="topArticleAjax"/>

 是不是更好,惟一要做的就是在action方法处理json转换.不过这不是主要问题,在参考json的转换模式上,我对json转换进行了改进.在Fly_m的注解上如下:

public @Interface Fly_m{
      String name() default ""; 
      String format() default ""; 
      boolean exclude() default false; 
}

 支持如json一样的名称和format以及exclude(如果为真则不进行转换).另外,支持排除指定类(如果转换对象类型和排除类一致而不进行转换)和指定名称的对象(如果对象名称和排除对象名称一致,则被忽略,只限于对象和map.这对于hibernate这种相互调用的持久层对象最好了).如对象a.b.c的形式.默认的json转换是完全转换,在json插件上,如果在b上设定json(exclude),则无论如何b都不会被转换,这种方法太过固定,不支持临时配置.而在改进中,只需要加一个"a.b"形式的excludeProperties参数就可以了.如果想转换时,把参数去掉就行了.相应的转换方法如下:

public static String convertToJson(Object obj, String... excludeProperties) {
		return convertToJson(obj, null, null, excludeProperties);
	}

public static String convertToJson(Object obj, Format format, Class[] excludeClasses, String... excludeProperties) {
		JsonHandle jsonHandle = new JsonHandle();
		jsonHandle.excludeProperties = excludeProperties;
		jsonHandle.excludeClasses = excludeClasses;
		if(format != null)
			jsonHandle.defaultFormat = format;
		return jsonHandle.convertToJson(null, 0, obj);
	}

  而在jsonHandle中是这样处理的.

public String convertToJson(String s, int depth, Object obj) {
			if(obj == null || obj.getClass().getName().indexOf("$$EnhancerByCGLIB$$") != -1 || contains(excludeClasses, obj.getClass())) {
				sb.append("null");
			} else if(isSimpleType(obj.getClass())) {
				if(obj instanceof Character) {
					sb.append("'").append(obj).append("'");
				} else {
					sb.append(obj);
				}
			} else
			if(String.class.isAssignableFrom(obj.getClass()) || StringBuffer.class.isAssignableFrom(obj.getClass())
					|| StringBuilder.class.isAssignableFrom(obj.getClass())) {
				sb.append('"');
				CharacterIterator it = new StringCharacterIterator(obj.toString());

				for(char c = it.first(); c != CharacterIterator.DONE; c = it.next()) {
					if(c == '"') {
						sb.append("\\\"");
					} else if(c == '\\') {
						sb.append("\\\\");
					} else if(c == '/') {
						sb.append("\\/");
					} else if(c == '\b') {
						sb.append("\\b");
					} else if(c == '\f') {
						sb.append("\\f");
					} else if(c == '\n') {
						sb.append("\\n");
					} else if(c == '\r') {
						sb.append("\\r");
					} else if(c == '\t') {
						sb.append("\\t");
					} else if(Character.isISOControl(c)) {
						sb.append(unicode(c));
					} else {
						sb.append(c);
					}
				}

				sb.append('"');
			} else if(obj instanceof Collection) {
				boolean hibernateFlag;
				try {
					((Collection) obj).size();
					hibernateFlag = true;
				} catch(Exception ex) {
					hibernateFlag = false;
				}

				if(hibernateFlag) {
					sb.append("[");

					for(Iterator iterator = ((Collection) obj).iterator(); iterator.hasNext();) {
						convertToJson(s, depth, iterator.next());

						if(iterator.hasNext()) {
							sb.append(",\n");
						}
					}

					sb.append("]");
				} else {
					sb.append("null");
				}

			} else if(obj.getClass().isArray()) {
				sb.append("[");

				int max = java.lang.reflect.Array.getLength(obj);

				for(int i = 0; i < max; i++) {
					if(i > 0) {
						sb.append(",");
					}
					convertToJson(s, depth, java.lang.reflect.Array.get(obj, i));
				}

				sb.append("]");
			} else if(java.util.Map.class.isAssignableFrom(obj.getClass())) {
				if(sb.length() > 0 && sb.lastIndexOf(",") != -1) {
					sb.insert(sb.lastIndexOf(",") + 1, "\n");
				}
				sb.append("{");

				for(Map.Entry e : ((Map<?, ?>) obj).entrySet()) {
					if(!(e.getKey() instanceof String))
						continue;
					if(contains(excludeProperties, e.getKey().toString())) {
						continue;
					}
					if(sb.length() > 0 && sb.charAt(sb.length() - 1) == ',' && sb.charAt(sb.length() - 2) == '}') {
						sb.insert(sb.length(), "\n");
					}
					sb.append("\"").append(e.getKey()).append("\"").append(":");

					if(depth <= DEFAULT_DEPTH) {
						convertToJson(add(s, e.getKey().toString()), depth + 1, e.getValue());
					} else {
						sb.append("undefined");
					}

					sb.append(",");
				}

				if(sb.length() > 3) {
					sb.deleteCharAt(sb.length() - 1);
				}

				sb.append("}");
			} else {
				Map map = null;
				try {
					map = getPropertiesByReflect(this, obj);
				} catch(Exception ex) {
					ex.printStackTrace();
				}

				convertToJson(s, depth, map);
			}
			return sb.toString();
		}
	}

 相关的转换方法都参照了其他的处理方式,具体解析方法请参照附件中的JsonUtils类.

 这篇文章只是说明了一种对于json的一种新的处理方式,并不是对于json插件的不满,当然我还是喜欢自己的处理方式.加上前面对乱码的处理,算是对struts2的一种补充吧.

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

    最近要用struts2做一个体育类的系统,由于系统本身的原因(要求可操作性强,用户交互性高),所以不可避免地要用到ajax.在我的前一篇文章里已经提到了有关在struts2中运用ajax的一些东西了.这次重新再拾起来,仔细对比下其中的差别.
    在前一个例子性系统中,由于所有的编码都是以UTF-8进行编码的,所以也没有碰到过有关乱码的问题.普通调用和ajax调用都很正常地运行了.而在新的系统中,要求所有的页面(包括数据库)都要求运用GBK编码.这样,一些有关于乱码的问题就出现了,乱码...与struts2有关. 
    大家都知道,在struts2的配置文件中,有一个配置项直接跟编码有关."struts.i18n.encoding"这个配置项表示struts2将对数据进行何种形式的编码操作,默认的编码为utf-8,这也是为什么在前一个新闻系统中没有乱码的原因,因为它本身都和系统默认编码一致.而在新的系统中,由于要求必须将编码改成GBK,配置如下:

<constant name="struts.i18n.encoding" value="GBK"/>

   在这种情况下,加上在tomcat serve.xml中修改URIEncoding=GBK,保证传送到服务器的数据都是GBK格式.实际测试中,这种方式是正确的,编码正确.
   然而好境不长,当运用到ajax时,问题出现了.我最先采用的是struts2的json插件,看它的要求,它要求工程编码应该为UTF-8,而我的工程编码实际为GBK,这是不可能改回去的事情.先不管它,在页面中配置完成,进行ajax调用.果然,数据乱码.在action中,对数据进行了测试,发现数据在进行action时已经是乱码.对数据进行转码操作,发现将数据按

x = new String(x.getBytes("GBK"),"UTF-8");

 时,数据正常了.这就表示数据是按照utf-8格式进行传送的,而在sturts中可能将数据又转回了gbk,导致乱码产生.一开始从js入手,因为我用的prototype.js采用post进行传送.设置的encoding为"UTF-8",修改js的encoding为"GBK",发现并没有按照想像的方向发展,仍然乱码.而采用get方式发送时,数据仍然是乱码.
     只有从java方向入手了,处理方向有两种,就像我在前面两篇有关jsp乱码中提到一样.第一种是加拦截器,拦截到ajax请求时,将编码重新转码操作.第二种就是像过滤器一样,在进行参数编码前设置正确的编码.在struts2中采用的是第二种方法.其实struts.i18n.encoding采用的也是这种方法.相应的代码如下:

public void prepare(HttpServletRequest request, HttpServletResponse response) { 
        String encoding = null; 
        if (defaultEncoding != null) { 
            encoding = defaultEncoding; 
        }

        Locale locale = null;

        if (defaultLocale != null) {
            locale = LocalizedTextUtil.localeFromString(defaultLocale, request.getLocale());
        }
        if (encoding != null) { 
            try { 
                request.setCharacterEncoding(encoding); 
            } catch (Exception e) { 
                LOG.error("Error setting character encoding to '" + encoding + "' - ignoring.", e); 
            }
        } 
        if (locale != null) { 
            response.setLocale(locale); 
        } 
        if (paramsWorkaroundEnabled) { 
            request.getParameter("foo"); // simply read any parameter (existing or not) to "prime" the request 
        } 
    }

 这个方法这是org.apache.struts2.dispatcher.Dispatcher中而被FilterDispatcher调用,后都大家都知道吧,是struts2的标准过滤器.它调用的地方如下:

protected HttpServletRequest prepareDispatcherAndWrapRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException { 
 
        Dispatcher du = Dispatcher.getInstance(); 
 
        // Prepare and wrap the request if the cleanup filter hasn't already, cleanup filter should be 
        // configured first before struts2 dispatcher filter, hence when its cleanup filter's turn, 
        // static instance of Dispatcher should be null. 
        if (du == null) { 
 
            Dispatcher.setInstance(dispatcher); 
 
            // prepare the request no matter what - this ensures that the proper character encoding 
            // is used before invoking the mapper (see WW-9127) 
            dispatcher.prepare(request, response); 
        } else { 
            dispatcher = du; 
        } 
         
        try { 
            // Wrap request first, just in case it is multipart/form-data 
            // parameters might not be accessible through before encoding (ww-1278) 
            request = dispatcher.wrapRequest(request, getServletContext()); 
        } catch (IOException e) { 
            String message = "Could not wrap servlet request with MultipartRequestWrapper!"; 
            LOG.error(message, e); 
            throw new ServletException(message, e); 
        } 
 
        return request; 
    }

 由上可以看出,filter在实例化dispatcher后,调用其的prepare方法,而prepare方法中,好像涉及到的其他相关操作不多,只是操作request 和 response的,在prepare方法中,判断encoding是不是空,如果不为空则将其设置编码入request中.而在defaultEncoding的设置上,可以看出这个参数是跟struts.i18n.encoding相关的,相关代码如下:

@Inject(StrutsConstants.STRUTS_I18N_ENCODING) 
    public static void setEncoding(String val) { 
        encoding = val; 
    }

 在上面这个方法中,将把struts.i18n.encoding注入到encoding中,也就是说,如果我们设置encoding为GBK,无论在何种条件下,它就是GBK编码了.
      尝试修改这种方式,因为直接影响的就是

prepareDispatcherAndWrapRequest(HttpServletRequest request, HttpServletResponse response) 

这个方法,于是直接修改如为如下:

public class TextFilter extends FilterDispatcher{
	private static final Log log = LogFactory.getLog(TextFilter.class);
	private FilterConfig filterConfig;

	private static String defaultEncoding;
	private static String defaultLocale;
	private static String paramsWorkaroundEnabled = "false";

	@Inject(org.apache.struts2.StrutsConstants.STRUTS_DISPATCHER_PARAMETERSWORKAROUND)
	public static void setParamsWorkaroundEnabled(String enabled) {
		paramsWorkaroundEnabled = enabled;
	}

	@Inject(StrutsConstants.STRUTS_I18N_ENCODING)
	public static void setEncoding(String encoding) {
		defaultEncoding = encoding;
	}

	@Inject(value = StrutsConstants.STRUTS_LOCALE, required = false)
	public static void setLocale(String locale) {
		defaultLocale = locale;
	}

	public void init(FilterConfig filterConfig) throws ServletException {
		super.init(filterConfig);
		this.filterConfig = filterConfig;
	}

	protected HttpServletRequest prepareDispatcherAndWrapRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException {
		Dispatcher du = Dispatcher.getInstance();

		if(du == null) {
			Dispatcher.setInstance(dispatcher);
			prepare(request, response);
		} else {
			dispatcher = du;
		}

		try {
			request = dispatcher.wrapRequest(request, getServletContext());
		} catch(IOException e) {
			String message = "Could not wrap servlet request with MultipartRequestWrapper!";
			log.error(message, e);
			throw new ServletException(message, e);
		}

		return request;
	}

	private void prepare(HttpServletRequest request, HttpServletResponse response) {
		String encoding = request.getCharacterEncoding();
		if(encoding == null) {
			encoding = defaultEncoding;
		}

		Locale locale = null;
		if(defaultLocale != null) {
			locale = LocalizedTextUtil.localeFromString(defaultLocale, request.getLocale());
		}

		if(encoding != null) {
			try {
				request.setCharacterEncoding(encoding);
			} catch(Exception e) {
				log.error("Error setting character encoding to '" + encoding + "' - ignoring.", e);
			}
		}

		if(locale != null) {
			response.setLocale(locale);
		}

		if(isParamsWorkaroundEnabled()) {
			request.getParameter("foo");
		}
	}

	public boolean isParamsWorkaroundEnabled() {
		ServletContext servletContext = filterConfig.getServletContext();
		return servletContext != null && servletContext.getServerInfo() != null && servletContext.getServerInfo().indexOf("WebLogic") >= 0 ||
				paramsWorkaroundEnabled.equalsIgnoreCase("true");
	}
}
 

 可以看出,整个就是继承filterDispatcher,再修改其中的一个方法.将dispatcher.prepare()这一名改成filter.prepare的形式,实际上效果是一样的.惟一让人感觉不爽的就是,由于在filter中设置的各种变量都是私有而且是是静态的(我尝试用反射都不能得到它的值),导致直接不能得到父类的属性值,没办法,只有再加变量了.在上面的prepare中,判断request中的编码是不是为空,一般来说,从jsp页面传送的编码都是空的.当由js进行传送时,由于已经设置传送编码为UTF-8,故getCharacterEncoding()不为空,则不再进行设置编码了.其他由设置传送编码为defaultEncoding(即sturts.i18n.encoding).
在上面的有一句

if(isParamsWorkaroundEnabled()) { 			request.getParameter("foo"); 		}

专为weblogic设置,由于没有接触过,略过.值得不提的是,request.getParamter("foo").这一句,在tomcat里面是直接将编码固定化,即只要调用了这一句,都将使得request(在tomcat的实现中)不能再接受其他编码(参数已经被转化了).
最后,将filter设置在struts.xml中,以便窗口将参数@inject注入到filter中.

<bean class="m_ylf.cs.sicau.struts2.TextFilter" static="true"/>

 上面一句必须要,不然相应的静态参数都没有被注入,是会产生NullPointerException的哦.
先解决这一个问题,下一个问题将介绍struts2的json插件,及改进方法.

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

      这篇文章我是继看过帖子 http://www.javaeye.com/topic/173295 之后写下的一些经过和学习经验,尽管以前也简单看过一些关于webwork验证的东西,但都因为没有进行深入研究而作罢,直到看了论坛帖子之后,才想专心去看一下相应的解决办法.(注:写本文的目的只是让自己能有一个记性,同时也将相关的东西统一起来,让大家也都能够了解一些,如果有人也解决过这个问题,不妨一起说说经历).

       很早以前就利用struts2(其实就是webwork核心)的验证框架,写各个方法的验证文件了.如我有一个名叫ArticleAction的类,其中需要调用一个叫做showArticle方法,那么我的action配置可能是这样写的:

<action name="sa2" class="articleAction" method="showArticle">  	<result name="input">/WEB-INF/news/error.jsp</result>  	<result name="ARTICLEACTION_SHOWARTICLE_SUCCESS">/WEB-INF/news/articleShow.jsp</result>  	<result name="ARTICLEACTION_SHOWARTICLE_FAIL">/WEB-INF/news/error.jsp</result>  </action>

  这样,在我的源代码中,就有一个名叫Article-sa2-validation.xml的校验文件.这里注明一下,如果配置文件里面已经注明了方法,如上文所示,那么相应的校验文件中的方法应该是action的配置别名,而不是showArticle.我以前写Article-showArticel-validation,它死活都不解析,最后去找英文论坛好不容易看到这么一条配置,终于解析了.

验证文件就不用写了,那么我们继续帖子上的内容,在看了webwork中文wiki上的java5注解配置,同时受帖子启发,把相关的验证都搬到Action源代码中,并删除了xml验证文件.

     这里要注明一下,帖子中作者的注明其实只有一个是需要被验证的,而我自己的action中,是有很多方法被验证,同时每个访求所验证的对象还可能不一样.由以下这个action配置文件来说:

<action name="sa1" class="articleAction" method="saveArticle">  			<interceptor-ref name="defaultStack"/>  			<interceptor-ref name="token"/>  			<result name="invalid.token">/WEB-INF/news/success.jsp</result>  			<result name="ARTICLEACTION_SAVEARTICLE_FAIL">/WEB-INF/news/articleCreate.jsp</result>  			<result name="ARTICLEACTION_SAVEARTICLE_SUCCESS">/WEB-INF/news/success.jsp</result>  			<result name="input">/WEB-INF/news/articleCreate.jsp</result>  		</action>  		<action name="sa2" class="articleAction" method="showArticle">  			<result name="input">/WEB-INF/news/error.jsp</result>  			<result name="ARTICLEACTION_SHOWARTICLE_SUCCESS">/WEB-INF/news/articleShow.jsp</result>  			<result name="ARTICLEACTION_SHOWARTICLE_FAIL">/WEB-INF/news/error.jsp</result>  		</action>

这里就有两个验证一个是sa1,一个是sa2,而对sa1所验证的主要是article这个对象的相关属性(具体属性就不用由贴出来了,主要就是些标题啊,内容啊什么的),而sa2所验证的是一个article.id这个对象是否为空就完了,因为它必须要求这个属性不能为空才能调用相关的方法逻辑.相应的annotation我贴出来,看下验证的内容:

@Validations(requiredStrings = {  	@RequiredStringValidator(fieldName = "article.title", key = "article.title.requiredstring", message = "null"),  	@RequiredStringValidator(fieldName = "article.content", message = "null", key = "article.content.requiredstring"),  	@RequiredStringValidator(fieldName = "article.titleColor", key = "article.titleColor.requiredstring", message = "null"),  	@RequiredStringValidator(fieldName = "article.tags", key = "article.tags.requiredstring", message = "null")})  	public String saveArticle() throws Exception {}

@Validations(requiredFields = @RequiredFieldValidator(fieldName = "article.id", key = "article.id.required", message = "null"),  			conversionErrorFields = @ConversionErrorFieldValidator(fieldName = "article.id", message = "null", key = "article.id.int"))  	public String showArticle() throws Exception {}

 从上面可以看出,两者进行验证的内容是完全不一样的.好了,改写完毕,进行tomcat运行了.先运行一下第一个方法,恩一切正常,验证也是正常的.然后运行第二个方法,结果出错了,页面上一堆验证失败信息,而令人奇怪的是,除了对于第二个方法的验证错误之外,所有每一个方法的验证错误都出来了.刚开始还以为是配制出错的原因,检查了几次都还是有错.我尝试将第一个的验证改成@SkipValidation,结果出来了,第二个验证开始起作用了,也就是说第一个的验证没有出现了.但是这很正常的呀,把第一个禁用了(SkipValidation)了,当然不会出现第一个的验证了.我觉得好像虽然是写在方法级别上的验证,而实际的作用范围却是每一个方法,于最初的要求还是有那么一大段区别.我认为可能是源代码中哪儿逻辑错了或者说配置错了.于是,先是去google,不过查了很久,都没有查到跟这个问题相关的地方,很多页面都说了struts2(webwork)的annotation验证,却没有说碰到这种情况,因为相应的验证都是放在field上或者说是单独的一个方法之上(如中文webwork wiki中写的),还是自己动手吧.

 说干就做,下载 了struts2的源代码,在用于验证的拦截器AnnotationValidationInterceptor 这个方法的doIntercept(ActionInvocation actionInvocation)是这样写的:

protected String doIntercept(ActionInvocation invocation) throws Exception {         Object action = invocation.getAction();         if (action != null) {             Method method = getActionMethod(action.getClass(), invocation.getProxy().getMethod());             SkipValidation skip = (SkipValidation) method.getAnnotation(SkipValidation.class);             if (skip != null) {                 return invocation.invoke();             }         }         return super.doIntercept(invocation);     }

protected void doBeforeInvocation(ActionInvocation invocation) throws Exception {         Object action = invocation.getAction();         String context = invocation.getProxy().getActionName();         String method = invocation.getProxy().getMethod();         if (validateAnnotatedMethodOnly) {             ActionValidatorManagerFactory.getInstance().validate(action, context, method);         } else {             ActionValidatorManagerFactory.getInstance().validate(action, context);         }     }     protected String doIntercept(ActionInvocation invocation) throws Exception {         doBeforeInvocation(invocation);                return invocation.invoke();     }

 由上文可以看到,有一个判断,判断validateAnnotationMethodOnly这个标志,如果为false,进行第二个验证,而第二个验证的代码可以看到是这样写的

public void validate(Object object, String context) throws ValidationException {          validate(object, context, (String) null);  }

  也就是说,第二个验证调用的是第一个方法,只不过方法参数为null.现在来看,既然,带了方法这个参数,那么应该就是对访求进行单独设置的才对呀,那为什么会那样呢,接下去看.

public void validate(Object object, String context, ValidatorContext validatorContext, String method) throws ValidationException {          List<Validator> validators = getValidators(object.getClass(), context, method);          ......//中间省略若干                  validator.validate(object);              } finally {                  validator.setValidatorContext( null );              }          }      }

public void validate(Object object, String context, ValidatorContext validatorContext, String method) throws ValidationException {          List<Validator> validators = getValidators(object.getClass(), context, method);          ......//中间省略若干                  validator.validate(object);              } finally {                  validator.setValidatorContext( null );              }          }      }

  看样子就是得到该方法的验证器,再验证此对象了.而对于上面的几个方法来说,validator.validate(object)是最终的验证手段,而第一步才是最关键的,得到该对象,方法的所有验证.进入方法:

public synchronized List<Validator> getValidators(Class clazz, String context, String method) {          final String validatorKey = buildValidatorKey(clazz, context);           if (validatorCache.containsKey(validatorKey)) {              if (FileManager.isReloadingConfigs()) {                  validatorCache.put(validatorKey, buildValidatorConfigs(clazz, context, true, null));              }          } else {              validatorCache.put(validatorKey, buildValidatorConfigs(clazz, context, false, null));          }           // get the set of validator configs          List<ValidatorConfig> cfgs = validatorCache.get(validatorKey);           // create clean instances of the validators for the caller's use          ArrayList<Validator> validators = new ArrayList<Validator>(cfgs.size());          for (ValidatorConfig cfg : cfgs) {              if (method == null || method.equals(cfg.getParams().get("methodName"))) {                  // Remove methodName temporary                  Object methodName = cfg.getParams().remove("methodName");                  Validator validator = ValidatorFactory.getValidator(cfg, ObjectFactory.getObjectFactory());                  // Readd methodName temporary                  cfg.getParams().put("methodName", methodName);                  validator.setValidatorType(cfg.getType());                  validators.add(validator);              }          }           return validators;      }

  这个流程也很简单,好像就是得到类上的验证,字段上的验证,还有就是方法级别上的验证.而在我们的程序中,类级别上的验证没有,字段上的验证也没有,所以就只有方法级别上的验证了.最后几句最为关键,它好像是进行了方法判断,并将难过的验证放在list中,并返回.其中它的判断很特别:

if (method == null || method.equals(cfg.getParams().get("methodName"))) {}

  前面有一个对方法的空判断,而后面有一个方法名的判断.这时我想到了,如果一路上将方法带上的话,那么这里如果没有出错的话应该是只会加上特定方法上的验证的,而如果方法本身就是空的,那么这里就会把所有配置上的验证加在验证列表中,也就是说,本身上属于第一个方法的验证也会被加上.为了验证这种想法,我对原文件进行验证性输出,结果果不其然,method是空,而且同时输出的各个加进来的验证中,果然就本来属于第一个方法的requiredstring等验证.

那么为什么方法是空的呢,如果xwork是正确的,那么结论就肯定出现在当初最先进入验证的源头,validate(...)上.一开始以为是方法没有得到,重新打印输出一下,结果发现这里方法是被得到的.那么,问题肯定出现在接下来的

if (validateAnnotatedMethodOnly) {

  上了,一查果然这个参数是空的,那么它肯定进入无方法的验证了,也就是说所有的验证都是进入验证列表了.
为了解决这个问题,看了下这个拦截器的写法,发现它是一个经典的webwork的写法,它提供了对validateAnnotatedMethodOnl这个参数的可配置性,那么如果将这个参数配置成true的话,那么肯定就只进行方法级别的验证了.再看了一个struts2的默认配置,终于发现原来可以在struts2的配置中,对这个值进行依赖注入,参加它本身的写法:

<interceptor-ref name="validation">  					<param name="excludeMethods">input,back,cancel,browse</param>  				</interceptor-ref>

  它配置默认对几个方法名不拦截,那么我们再加上以下一条:

<interceptor-ref name="validation">  					<param name="excludeMethods">input,back,cancel,browse</param>  					<param name="validateAnnotatedMethodOnly">true</param>  				</interceptor-ref>

  这样就可以调用有方法的验证了.结果实验了一下,果然程序依照自己的思路正确的运行了.

根据这次收获,发现原来自己解决问题也是很高兴的,不知道struts2里面怎么把这个默认给关了, 难道是希望用xml的方式进行验证,而且几乎没有文档提供这个参数的作用,还得靠自己来才行.

突然想到一点,如果我靠这个判断,那么如果是没有验证Annotation的方法,那么它就没有validation了,那么是不是就不会进行验证了?试验了一把,果然没有进行验证(或者说方法上没有可验证的validation).帖子中提到的加SkipValidation的方法,这是在struts2的层次上进行验证的提前结束,不过如果不验证的方法很多的话,那不是要写很多的@SkipValition了.如果不写这个,利用xwork本身的验证就会根本上通过这个方法,且xwork的验证是通过cache进行了,也就是说,它的validator都是存储在cache中的,对系统的影响了不会有很大吧.不知道struts2电门弄这个@SkipValidator是什么意思,且这个好像是专门为AnnotationValidatorInterceptor服务的,难道是没有想到本身就是不需要的吗,不解.所以看到帖子说很多地方要加@SkipValidator这个东西,本身也觉得很矛盾的,看来是多心了.根本不用加,因为它本身就没有validator所以,不需要进行验证.直接就通过了.:)

Fly_m 2008-3-21

附件中为一个验证Action和一个struts.xml配置文件.

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

if(ignore || (request.getCharacterEncoding() == null)) {
	String encoding = selectEncoding(request);
	if(encoding != null) {
		request.setCharacterEncoding(encoding);
	}
}

protected String selectEncoding(ServletRequest request) {
               if(request.getParameter("ajax") != null)
		return null;
               return this.encoding;
}

public String getParameter(String name) {
        if (!parametersParsed)
            parseParameters();

        return coyoteRequest.getParameters().getParameter(name);
}

protected void parseParameters() {
        parametersParsed = true;
        Parameters parameters = coyoteRequest.getParameters();
        String enc = getCharacterEncoding();
......
}

 这个访求将parametersParsed置真,那么,如果这个为真的话,那么这个方法就不会被执行,也就是说,再不会进行转码操作.parseParameters只会被进行一次,也就是说,如果我调用了,getParamters这个方法之后,再进行setCharacterEncoding方法,将不会对parseParameters方法有任何影响,因为这个方法已经被执行了,而依据的编码是之前的旧的编码.在上面那个selectEncoding中,我执行了一个request.getParameters()方法,相关的编码已经固定下来了,所以接下来的编码都不会对参数的编码问题有影响.所以,在执行编码设置之前,不能调用任何getParameters()方法,可能还有其他方法(暂时不管其他的).这就难办了.
        忽然想看看,ajax调用之前的编码是什么,结果打印出来结果为UTF-8,而对jsp之前的编码进行打印时,却是null.仔细看了下,doFilter之个方法,还有那个if语句.很简单,如果request.getCharacterEncoding()不为空时,是可以不用再设置编码为GBK了,而当为null时,则可以设置编码.再仔细看了下这个ignore参数,它现在默认是true,也就是说,如果它为true,那都会强制进行设置编码操作,于是一个新的办法出来了.将ignore设置为false,每次设置编码由request来决定,如果编码为null则设置为GBK,否则就按已经设置好的编码(如ajax的UTF-8)进行.
       因此将selectEncoding改回去,原来的不变,然后在web.xml中,对setCharacterEncoding的初始化参数进行修改,将ignore改为false,这样整个问题就解决了.
      事后看了下这个问题,其他也很简单的,就是修改一个ignore参数的问题,然而却费了这么长的时间.原因还是自己对这个问题不太明白,以前看ignore这个参数觉得没什么用嘛,原来在这些问题还发挥了作用,最后还去看源代码,本来很简单的一件事,费这么大功夫,虽然有点不值,还算是买了个念像,以后碰到这个问题应该就不会再出问题了.
Fly_m 记.

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

import javax.servlet.*;
import java.io.IOException;

public class SetCharacterEncodingFilter
		implements Filter{

	protected String encoding = null;
	protected FilterConfig filterConfig = null;
	public void destroy() {
		this.encoding = null;
		this.filterConfig = null;
	}
	public void doFilter(ServletRequest request, ServletResponse response,
			FilterChain chain) throws IOException, ServletException {
		/** Conditionally select and set the character encoding to be used */
		if(ignore || (request.getCharacterEncoding() == null)) {
			String encoding = selectEncoding(request);
			if(encoding != null) {
				request.setCharacterEncoding(encoding);
			}
		}
		/** Pass control on to the next filter */
		chain.doFilter(request, response);
	}
	public void init(FilterConfig filterConfig) throws ServletException {

		this.filterConfig = filterConfig;
		this.encoding = filterConfig.getInitParameter("encoding");
		String value = filterConfig.getInitParameter("ignore");
		this.ignore = value == null || value.equalsIgnoreCase("true") || value.equalsIgnoreCase("yes");
	}
	protected String selectEncoding(ServletRequest request) {
		return this.encoding;
	}
}

这样在web.xml中加入此filter,并设置ignore为true和encoding为GBK.
       本来以为事情就这样完了,不想在进行ajax调用时,就出现问题了.ajax里面也分两种方式,一种是get,一种是post.其中以get方式进行调用时,是没有问题的.参数被正确地传递到action中,而以post方式进行调用时,麻烦就出来了,action中的中文参数全部成了乱码.在网上查了一下,ajax的post请求是以utf-8进行编码的,当用filter进行过滤时,自然就成了乱码了.由于在系统中的ajax调用是经过封装的,采用的方式是以post进行调用,且参数也多,可能查询的参数也不是get所能传递的,个人也不太欣赏get方式进行ajax调用.所以就不想修改现有的ajax调用方式,坚决用post方式.
      接下来就想从这个filter中下手,只要接受到ajax请求时,不再进行编码操作,而是以默认的utf-8进行编码.由于我写的ajax调用里面有个特殊的参数为ajax=true这个查询字符串.就想到了用拦截串这个东东,将ajax请求的编码再转换为utf-8编码.所以就写了如下的一个拦截器,进行编码转换.

public class Xx extends AbstractInterceptor{
	@SuppressWarnings("unchecked")
	public String intercept(ActionInvocation actionInvocation) throws Exception {
		Map paramMap = actionInvocation.getInvocationContext().getParameters();
		if(paramMap.get("ajax") != null) {
			for(Object key : paramMap.keySet()) {
				if(key instanceof String) {
					String value = (String) paramMap.get(key);
					paramMap.put(key, new String(value.getBytes("GBK"), "UTF-8"));
				}
			}
		}
		return actionInvocation.invoke();
	}
}

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

在上个公司的项目中,由于用到了导师在年前所参与写的一个开源框架.http://www.open-open.com/open155318.htm 并在运用的过程中碰到些存在的问题,故将碰到的问题列出来,与大家分享.
      由于是导师的框架,所以不存在什么乱改写的问题,况也只有内部在使用,其实也是为了自己开发上的需要,对原有的相关的代码进行功能上的补充和改进,以实现更多的功能.
     1,对非持久性数据字段的支持,在原来的框架中,由于域模型字段与数据库字段一致,故采用自动保存,即调用save(object)时,它会自动分析对象的各个属性,并将所有的属性作为数据库的字段处理.而在实际中,并非所有的属性都需要被存储,如一些模型中的集合属性或者一些不用于数据存储的属性.参考原代码中用于代码存储的一段,即用于读取各个属性并生成sql语句这一行,加入特殊标记判断,对于transient的属性将其忽略,不将其列入存入数据库中的字段.(这个设计同样影响对于update等操作,不过由于数据库的相应表并不存在与transient属性对应的列,故此举并不会影响update操作的正常进行)相关代码如下:

 2,在上次的项目中,用这个框架对统计进行一次初始统计,居然不能正常完成.查其原因,发现在底层居然是采用每一次重新建立数据库连接并结束再建立的方式,且在建立过程中还要重新读一次配置文件.效率十分低下.解决方法,在配置过程中建立一个小小的配置缓存,在下一次读取时,直接返回相应缓存的结果.而重点在于如何解决每一次访问数据库都要重新建立连接的问题.由于此框架并没有实现连接池,查看了相应的代码,框架重新建立数据库连接无非也就是获得一个Connection对象,所以我想在其他地方引入一个connection对象(如池化的connection对象),并将其配入框架中,在框架的初始配置代码中引入connection属性,在获取连接时,首先尝试获得初始被外界传入的connection对象,如果外界没有传入,再由框架自身解析获得.仔细分析了一下代码,代码的入口点在EngineImpl类中,此类需要一个connection对象作为构造参数.所以,需要一个dataSource对象,再将dataSource对象产生的connection对象传入EngineImpl类的构造参数就OK了.这个connection对象是由外部的数据访问模板SpeedTemplate调入的,由SpeedTemplate只要接受一个可选的dataSource属性就可以实现将池化的connection对象传入整个框架中了,并且这个connection对象还由连接池来管理,而在框架中只是完成相应的数据访问操作.相应方式对比如下:
原先的方式:

java 代码

之后就是调用配置文件进行DriverManager.getConnection()并将connection传入EngineImpl如下

而修改之后的调用方式则如下:

这两者都是得到一个connection再将其传入EngineImpl,只是得到的方式不一样而已.在speedTemplate里面,得到一个Engine对象,首先判断dataSource属性是否为空,如果不为空,则采用dataSource的方式,否则采用getEngine(connectionFactoryId)即自已的解析方式.我还是喜欢连接池的方式.

3,模型字段与数据库字段大小写不一致的情况.我在用这个框架时,经常是手动书写插入和更新语句,因为我的对象的属性名都是大小写混合的,如testProperty,由数据库中的列为test_property,为了能让在查询中能够返回testProperty的列名,我经常采用select test_property as testProperty的写法.但还是报出property not found by :testproperty的异常,仔细看了下代码,发现代码中各处都是调用sql.toLowerCase()方法将sql语句转为小写.修改代码,将toLowerCase()去掉之后,问题解决.但是后来,将数据库转为oracle时,发现所有的列名又不可用了.仔细看了下oracle传回的数据,发现所有返回的列都是大写的!!!在mysql下,返回的列是跟程序中指定的列的大小写一致的,而到了oracle所有列都变成了大写了.在不改动项目程序的基础之上,尝试改写框架中对于返回数据处理这一段.在这一层建一个列属性(并将列属性改为小写)与对象属性名称之间的一个映射.列属性由传回的列名得到,而对象属性由对象本身通过反射得到.并将这一映射存入一个映射缓存中.在处理返回数据时,首先由得到列名及指定列的数据(由rs.getColumnName(int)得到),得到列名及数据之后,将列名.toLowerCase()之后与属性映射中得到正确的对象属性名称,再通过propertyUtils将指定的对象属性值写入正确的属性中去.相应代码如下:

这样就实现了不同格式列名与属性之间的映射关系了.

这个框架是自从跟导师在一起学习的时候就在运用这个框架,当然它的若能远远不及hibernate等orm框架.不过在进行简单的开发上面,还是不错了.现在仍然在用,是因为实习的公司要求用这个,(因为导师跟公司的关系很好,框架都是导师介绍过去的).在运用的过程中,发现新的问题,也想要去解决它.可能是这个框架不太成熟吧,导致它有太多的bug了,不过对于现在的学习还是不错的.尤其是对于它的属性映射,及sql语句的动态生成,了解一下,对hibernate之类的框架的工作原理还是有一定帮助的. 在跨平台上,也可能有一些值得借鉴的地方. 我最欣赏的还是框架对于分页的处理.在hibernate中,需要配置不同的dialect属性,才能运用数据库自身的分页功能,而speed则尝试自己获得数据库的属性,然后根据不同的数据库属性采用特定于数据库的分页方式.其底层原理和hibernate都是差不多的.任何框架,只会用,而不知其所以然,到头来也是什么也不知道,了解多一些,自己掌握多一些总是好的.

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

       在前面的新闻系统设计中,常常会用到有关ajax的请求,如对文章类别的动态调用.本来struts2提供了一个json的插件,不过在开发的时候还不知道.自己写了一个,还将就吧.
      基本原理,就是改变struts2的返回类型,原来的返回类型为string,如果返回类型为void即不返回任何类型,而改由struts2的的ServletContext对象获得用到输出的out对象,将json对象输出到页面上,同样可以达到ajax格式效果.最后在页面上作了小小的操作,将json格式的字符串变成js对象进行调用,以完成相应操作.流程如下:

1. 获得response对象,进行获得printWriter对象
2. 将想要返回给页面上的对象转化成json格式的字符串
3. 由printWriter将json字符串写到页面输出流(通常是被js来获得结果)
4. 页面处理json字符串,转化成js对象,传入回调函数进行调用

这里主要用到几个对象ServletContext(这个是struts2的工具对象,可获得request,response等对象),JsonUtil(自己写的一个类,用到转化对象),protype.js(用到提交ajax请求,接收返回结果),此外,还有一个jsonUtil的辅助类BeanUtil(用到将javaBean转化成map对象).这里主要贴出jsonUtil的转换方法和BeanUtil的辅助方法,看这种方式是否合适.

        在JsonUtil里,主要对一个对象进行分析,采取不同的策略对不同类型的对象进行递归性地转化.对应集合类型,采用迭代地方式.而进行通用的javaBean对象,则先将其转化成一个map对象,然后再进行转化.在本程序中,用到了一个转化深度地概念,主要是防止某些类地无限属性或者递归属性.考虑到并不需要将对象中的每一个属性进行转化,这里引入了一个相当于Traisient的注释@Fly_m,作用到字段上(因为对javaBean的解析是以反射来解析的).如果解析的属性存在这个注解,则被忽略.(一开始想要transient的modifier属性,发现与hibernate相冲突(hiberante对于transient的属性也不会解析?).

#-----------------------------
在客户端,我采用protype.js提供的基本的ajax调用方法Ajax.Request(action,{method,parameters,onComplete,onException)这种访求进行服务器请求,同时写了一个小小的辅助js进行调用,以方便页面调用.Fly_m.js,使用这个js后,通常的调用被简单化为m_ylf.invoke(actionName,method,parameters,callBack).这样,只需要四个参数,同时内置调试参数设置,以及传递给callBack对象的不再是一个xmlHttpRequest对象,而是一个已经eval好的js对象,让使用更加方便.源码如下: