ssh第二天

       依旧是模仿，模仿了胡老师给的讲义，文件上传与下载。登录和验证页面跳转什么的都和第一天的差不多，主要是多了一个拦截器和java中文件的使用方法。

       出现的问题总是逃不了小的细节错误，这次程序写好后，调试时发现总是找不到资源，就连第一个index.jsp页面都跳不过去。查看了web.xml配置文件发现配置的路径没有错误呀。开始以外是部署失败了，把项目重新部署到tomcat上，还是不行。然后以为是tomcat出了问题，又重启了tomcat，依旧不行。我迷茫了，这个可是第一个页面啊，在执行这个页面之前也就这么点代码，怎么可能会出现找不到资源呢！在tomcat的webapp下明明可以找到这个项目嘛。

       然后我想，是不是后面的代码有错，而导致找不到资源。首先粗略的检查了一下struts.xml的代码，没发现什么错误。然后又去转向检查java类里的代码是否有错。还是没错。上网查了一下，有人说jar包冲突，于是我把所有的jar包都删了，需要jar包的代码全都报红。我没管它，我想报红无所谓吧，如果是jar包冲突，将冲突源去掉，应该有可能解决资源找不到的情况，反正试试看。可结果是依然找不到资源。

       找了好长时间，错误依然没找到。我静下来好好想了想错误源到底会出现在什么地方：1、web.xml文件出错。这是绝对能导致资源找不到的，但web.xml文件是我从其他类似工程中拷贝过来的，并且web.xml非常好理解，不可能出问题的。2、index.jsp文件出错。就算index.jsp出错了（逻辑错误），只要它存在都应该能找到它，不可能资源找不到。可index.jsp实实在在的是存在的。3、后面的java类中的代码出错。我觉得如果后面的代码的小错误就能导致页面找不到，那这个struts2的框架也太不好用了，java类中的小错误发生连调试的机会都不给，那得花多少时间去人工地毯式找错。一个项目那么多java代码，这不坑爹嘛！我觉得问题不在java类的代码中，即使有错误，也不是导致找不到资源的直接原因。4、接下来的剩下一个关键的中转站——struts.xml。struts.xml也是具有资源定位文件之一。它能通过匹配的方式定位到相应的类，相应的方法。再一次仔仔细细的检查了struts.xml，果然发现了一个小小的错误：包的路径中action这个单词拼成了acttion. 晕！

       我有想了下，为什么这个错误会导致资源定位不到呢？这个struts.xml发生作用的时期是在找到index.jsp页面之后啊？！未来的事怎么会对现在产生影响呢？难道这里不是顺序执行的？

       我做了合理性假设，假如是顺序执行的，那么必定后面对前面没有任何影响。如果是顺序执行的，那么xml就失去了配置文件的特征，只作为过程代码了，与一般的java类中的代码没区别了。如果，xml顺序执行，我怎么觉得每次访问，都要对代码解析，定位，执行。那么这个框架就太失败了。所以，假如是struts.xml文件在程序运行之前，甚至在部署的时候就做了配置工作，完成了全局统筹工作。把该铺设的管道都铺好，该建设的门呀，窗户呀，传送带呀，安保设施啊什么的全部建好，总比之后每次来都铺路好多了。xml、框架，也许就是这样吧，xml搭好了框架，就像建好了房子一样。

       明显，这样一分析，决定xml放在程序运行之前执行要更为合理，更符合大牛们的设计思路。

       这个实验，主要的目的应该是拦截器的使用。在上一个问题解决之后，又出了一个重大问题，就是拦截器的问题。我在登陆页面输入用户名和密码（静态代码内置的用户名密码）后，总是跳转不到welcome.jsp.总是跳回到login.jsp（能从页面闪动看出是跳转回来的，不是停滞在当前页面）。查看了相关逻辑的java类代码，没发现问题。于是决定是在拦截器中出错了，检查了拦截器，并打印了预设的放行路径。接着调试时，发现放行代码中不包括当前的路径（登录的路径）。

这个实验的拦截器主要做这样的工作：拦截没有经过登录就直接进入欢迎界面。很显然在登录界面处不应该被拦截，因为此时肯定没登陆，当然不能拦截登录的action。原本代码中确实给login的action放行了，但是在login.jsp 页面之前有个跳转到login.jsp的链接。这个链接用的是struts2的标签，通过struts.xml转发。

在这个连接中，直接使用【<s:a href=”login_loginBefore”>登录</s:a>】而并未使用login_loginBefore.action。使用后者就能直接放行。

       最后我对上传文件做了改进，原本的上传文件在服务器端的文件名是用UUID随机产生的，可读性不强，对用户的使用不友好，因此，我利用本地客户端上传的文件名作为服务器端文件名，为防止服务器端命名重复，我做了文件名的列表检查，对与上传文件的文件名与服务器端已有文件的文件名进行对比，若发生相同文件名则在原文件名后面加序号，跟windows新建文件一样，自动递增序号。

 

       上网查了下拦截器的工作原理，拷贝如下，做一个学习记录：

Struts2的拦截器的实现原理和过滤器的实现差不多，对你真正想执行的 execute()方法进行拦截，然后插入一些自己的逻辑。如果没有拦截器，这些要插入的逻辑就得写在你自己的 Action实现中，而且每个 Action实现都要写这些功能逻辑，这样的实现非常繁琐。而Struts2的设计者们把这些共有的逻辑独立出来，实现成一个个拦截器，既体现了软件复用的思想，又方便程序员使用。 Struts2中提供了大量的拦截器，多个拦截器可以组成一个拦截器栈，系统为我们配置了一个默认的拦截器栈 defaultStack，具体包括那些拦截器以及他们的顺序可以在 Struts2的开发包的 struts-default.xml中找到。在每次对你的 Action的 execute()方法请求时，系统会生成一个 ActionInvocation对象，这个对象保存了 action和你所配置的所有的拦截器以及一些状态信息。比如你的应用使用的是 defaultStack，系统将会以拦截器栈配置的顺序将每个拦截器包装成一个个InterceptorMapping(包含拦截器名字和对应的拦截器对象 )组成一个 Iterator保存在 ActionInvocation中。在执行 ActionInvocation的 invoke()方法时会对这个 Iterator进行迭代，每次取出一个 InterceptorMapping，然后执行对应 Interceptor的 intercept(ActionInVocation inv)方法，而intercept(ActionInInvocation inv)方法又包含当前的ActionInInvcation对象作为参数，而在每个拦截器中又会调用 inv的 invoke()方法，这样就会进入下一个拦截器执行了，这样直到最后一个拦截器执行完，然后执行 Action的 execute()方法(假设你没有配置访问方法，默认执行 Action的execute()方法 )。在执行完 execute()方法取得了 result后又以相反的顺序走出拦截器栈，这时可以做些清理工作。最后系统得到了一个result，然后根据 result的类型做进一步操作。