莫名其妙的解决了一个莫名其妙的问题

这两天使用ssh框架做一个cms的添加数据功能，本来很简单的一个功能，前天就写好了，昨天早上来了，想到昨天写的那个功能是在原来已经存在的一个类里写的，并且数据库中的表用的也是原来的，更严重的是还对原来的方法进行了修改，一想这么可能会对原来的业务逻辑方法有影响，就新建了一个action类，然后把新增的方法从原来类中提了出来，然后在struts的配置文件中改了下使用的控制类，下面是修改后的配置(中间的省略号是其他功能的配置，红色代码部分是后来测试加的）：

<package name="systemProfile" extends="miguring-default"
          namespace="/systemProfile">
          <interceptors>
               <interceptor name="myLogger"
                    class="com.unison.miguring.cms.interceptor.LoggerInterceptor" />
               <interceptor-stack name="MyStack">
                    <interceptor-ref name="myLogger"></interceptor-ref>
                    <interceptor-ref name="defaultStack"></interceptor-ref>
               </interceptor-stack>
          </interceptors></span>
	  .
	  .
          .
	  <action name="addConfig"
               class="com.unison.miguring.cms.web.action.systemConfig.LoadingPageConfigAction"
               method="addSystemConfig">
              <interceptor-stack ref="MyStack"/>
               <result type="json"></result>
          </action>
</package>

噩梦就这么开始了，只要访问这个action，系统直接就跳到了登录页面，刚开始认为是使用ajaxSubmit提交导致，然后将其改为向其它action请求提交，经过测试后没有问题，但是只要改为这个action请求就跳到登陆页面（注：该系统没有对登录权限进行控制，所以排除是登录验证逻辑导致的），折腾了一下午仍然没有改好，一直到晚上9点问题依旧，脑子混乱，索性去做其他事情了，先放一放。早上到公司后，想到是不是struts2的默认拦截搞得鬼呢？但是怎么才能验证这个疑问呢？于是通过Google大神找到下面这篇文章：http://www.cnblogs.com/suxiaolei/archive/2011/11/04/2236181.html，这篇文章里介绍如何查看struts2的拦截器的调用过程，但是对于我的问题来说实验了一下并没有什么作用，这下更可以确定请求就没有到该action里，直接就是action没有找到然后就跳到登录逻辑中了，因为配置的默认的请求为登录页面。既然这样不行的话只有自己写一个拦截器，然后在该拦截器中打印请求的信息，下面是我自定义的拦截器：

public class LoggerInterceptor implements Interceptor {

	@Override
	public void destroy() {
		// TODO Auto-generated method stub

	}

	@Override
	public void init() {
		// TODO Auto-generated method stub

	}

	@Override
	public String intercept(ActionInvocation invocation) throws Exception {
		// TODO Auto-generated method stub
		System.out.println("begin-----------------------------");
		// 找到运行的action对象，并打印对象的类名
		System.out.println("运行action的类名："
				+ invocation.getAction().getClass().getName());
		// 找到运行的ActionProxy对象，打印出action中要运行的方法名
		System.out.println("运行action中所执行的方法："
				+ invocation.getProxy().getMethod());
		// 获得运行action的上下文ActionContext，打印出请求参数
		Map<String, Object> params = invocation.getInvocationContext()
				.getParameters();
		for (String key : params.keySet()) {
			Object obj = params.get(key);
			if (obj instanceof String[]) {
				String[] arr = (String[]) obj;
				System.out.println("请求参数名:" + key);
				for (String value : arr) {
					System.out.println("请求参数所对应的值：" + value);
				}
			}
		}
		// 运行后续的拦截器 Action和Result
		String resultCode = invocation.invoke();

		// 在运行Action和Result之后，得到Result对象
		// 并且可以强制转换成ServletDispatcherResult，打印其下一个JSP的位置
		Result result = invocation.getResult();
		System.out.println(result);
		if (result instanceof JSONResult) {
			JSONResult result2 = (JSONResult) result;
			System.out.println("跳转的JSP:" + result2.getCallbackParameter());
		}
		System.out.println("end---------------------------------"+resultCode);

		return resultCode;
	}

}

然后将该拦截器配置到要访问的action配置中，最后在该拦截器中设断点进行跟踪，这时奇迹出现了，随着跟踪的进行请求竟然进入到了配置的action方法中。。。，实在是让人汗颜，紧接着我把自定义的拦截器配置拿掉，请求后照样可以正常工作，唉！莫名其妙。。。。。

过了一天我突然想到以前也有遇到过这样问题，但那次是自己开发，就没有管，没想到过了几天运行后又好了，所以我决定把这个问题记录下来，想看看大家是不是有遇到过同样问题？抑或这是不是struts2的一个bug呢？