佐证了这样一个原则，package存在，但action没找到，就自动去默认空间去找。如果package不存在，则自动向上一级目录找，一级级倒到根目录。 根目录再没找到，再去默认目录找
网上对于命名空间一致的说法为：
如果请求为/test/search/get.action，系统首先查找/test/search命名空间下是否有get的Action，如果有，则使用该Action处理用户请求。否则系统进入默认命名空间中寻找是否含有get的Action，不会去子目录下找。
如果请求为/login.action，系统首先在根命名空间查找login的Action，如果有，则使用该Action处理用户请求。否则系统进入默认命名空间中寻找是否含有login的Action。
默认命名空间中Action可以处理任何命名空间下的Action，而根命名空间中的Action只能处理根命名空间下的Action。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
因为上述跟我实际做的有点不相符，然后经过不断的测试，终于弄明白了。也不能说上述说法错误，只是有个前提条件。
使用的版本为Struts2.5.8
首先我配置了很简单的3个包，第一个为默认命名空间，第二个为根命名空间，第三个为/book命名空间。
-
<package name="wxl1" extends="struts-default">
-
<action name="def">
-
<result>/WEB-INF/content/first.jsp</result>
-
</action>
-
</package>
-
<package name="wxl2" namespace="/" extends="struts-default">
-
<action name="def">
-
<result>/WEB-INF/content/second.jsp</result>
-
</action>
-
</package>
-
<package name="wxl3" namespace="/book" extends="struts-default">
-
<action name="def">
-
<result>/WEB-INF/content/third.jsp</result>
-
</action>
-
</package>
当请求为/book/def，毫无疑问显示的是/book下的视图。
测试1、当请求为/abc/def时，显示的却是根命名空间下second.jsp的视图。不是应该先去abc下找，找不到去默认命名空间吗，为什么显示的是根命名空间下的视图。
测试2、当请求为/book/abc/def时，显示的是/book命名空间下的视图。竟然跑进子目录里找到了。
一开始我以为是版本更新造成的，然后我又加上一个命名空间为/book/abc的包，但是不配置action。
-
<package name="wxl4" namespace="/book/abc" extends="struts-default">
-
</package>
当加上命名空间为/book/abc的包后,
同样请求为/book/abc/def，显示的是默认命名空间下的视图，不再是/book命名空间下的了。
这就遵从了文章开头的说法，/book/abc下没找到，然后跑默认的命名空间下找，并不会去/book下找。
造成上述的原因就是：请求的命名空间没有定义过。struts会把请求的命名空间去掉一层，再找，找不到再去掉一层，直到命名空间为/，也就是去根命名空间下找了（随便给个/dsjhfsd/dsfsdf/sdhf/def请求，显示的也是根命名空间下的视图，当然根下要有def的action，否则还是到默认命名空间）。所以测试1显示的是根命名空间，测试2显示的是/book空间，因为去掉一层就找到了。
由此得到结论：
当请求到来时，找actioon会分为2步
1、struts首先决定使用哪个命名空间的包，决定的原则就是上述，一层层剥离，找到最相近的。
2、只有决定了使用哪个包之后，才开始找action，找action的原则就是文章开头的说法。