标签:
Spring现在是一个非常火的词,但凡你看到的一个东西,都会发现一句提供与Spring集成这样的字样,那么在SpringMVC这块,它又为大家埋下了什么坑呢?
SpringMVC结合了其它MVC框架的优点,所以你可以像使用Struts2一样的使用SpringMVC,而且也给了开发者足够的自由,但是就是这些自由,有时会让我们付出很大的代价。
大家都知道SpringMVC在注入的时候,直接把参数写到相应的Action请求中的方法头里就可以,可以不用添加任何其它注解。
关于@RequestParam的说法是这样的:如果参数名和变量名不一致,可以使用@RequestParam(name)告诉Spring,使用指定名字传参。
这种说法明明就是错误的。因为只有在Debug模式下编译时,参数名都会保留在class文件中,spring由此可以反射绑定。与之比较配合的是开发时eclipse默认就是Debug模式编译代码。这样也就导致了我的悲剧的发生。
上篇文章说到我们的项目虽然是Maven项目,但是之前都没有用Maven编译部署过,始终使用的是eclipse发布到tomcat中,然后进行打包部署的方式进行的。把项目改成Maven项目时,把debug给关了,结果导致了打包可以运行,但是一访问却报错:
Request processing failed;nested exception is java.lang.IllegalArgumentException:Name for argument type ....
排查了很久,后来看了下编译好的class文件,才发现这个问题。
发生这个问题,源于项目的不规范。还有当时造型SpringMVC时,没有对此进行约定,不管开发者是否知道此事,对于一个造型的人来说,选了SpringMVC却没有要求必须用@RequestParam的形式进行参数的声明是一个不可原谅的失误。
后来也问了下身边的人,发现有些公司进行了此事的强制要求,但是有些则没有。当我问被强制要求这个的人是否知道为何这样时,回答也是否的答案。
事虽小,但是引起我们的警示却不可小觑,时间的生活中,我们又是有多少只是按照别人的约定去做而不多问个为什么,不只需要知道要做什么,这只是刚做了第一步,还需要知道为什么这样做。
文章的最后写一句遗憾的事吧,对于项目的改造,我的提议被无情的否了,还是得靠我那4层Jenkins搭出来的部署来维持很长一段时间,有点小心窄,不过会画出图来进行记录,毕竟是我对于当前公司的一点贡献,只是没有被采取而已。而对于想要为公司带来新东西的人提出一个建议,一定要先了解一下当前的遗留的系统再提改进方案,而对于那些想要为经理提出建设性意见的人来说,一定做好被拒的准备,不管你准备的多无懈可击,总会有各种奇葩的回答……
你不知道的SpringMVC——@RequestParam必须要加上参数名
标签:
原文地址:http://blog.csdn.net/jianxin1009/article/details/43709783