使用Struts2约定插件时，即使未定义HelloWorld.java，插件也会自动将hello-world.action请求转发给/WEB-INF/content/hello-world.jsp。
请参阅http://struts.apache.org/release/2.1.x/docs/convention-plugin.html为此。
另一方面，我们将JSP文件放在WEB-INF下，以避免直接访问JSP文件。
我认为约定插件的这种行为破坏了JSP访问策略。任何人都可以通过简单地调用动态构建操作来直接访问JSP。
我说得对吗？！如果是，我们可以禁用此功能吗？
不，你不太正确。如果页面处于WEB-INF之下，则无法直接访问这些页面。约定插件根据约定从Action类创建附加的基于XML的配置。因此，您只能访问这些操作返回的结果。约定插件将其配置放在XWork包下，如文档和此答案中所述。因此，解决冲突是可能的，如果您不指定父包。您还可以使用约定注释来自定义生成的配置。默认情况下，约定插件扫描基本包下的类，这些类可以是可配置的struts或actions，并具有Action后缀。这些都是约定插件的默认配置。如果您想更改默认设置，可以在struts.xml中使用常量标记或在struts.properties中使用相应的属性。
然而，文件中并不清楚它是如何处理的
由URL 标识的无操作结果
此外，还不清楚用什么URL来识别它。我想你已经熟悉了无操作配置，在那里你可以在不执行操作的情况下返回结果SUCCESS，因为默认情况下使用操作类。但是，问题甚至不在这里。上面提到的约定插件及其创建的配置还放置了一个未知处理程序，该处理程序应该处理不存在配置的URL(即，不由约定创建)。这就是问题的根源。该插件也不允许替换/覆盖配置。令人高兴的是，有一个未知的处理程序管理器(如果需要，可以替换)，它通过"unknown-handler-stack"的迭代来处理未知的操作，由该管理器管理。使用处理程序堆栈，您可以配置未知处理程序的迭代顺序。注意，当处理程序返回操作配置时，循环结束。这意味着，如果您创建自己的未知处理程序并在堆栈中设置顺序，则可以绕过约定处理程序
。