Struts 2 Convention Plugin and JSP files under WEB-INF

Question

When using Struts2 convention plugin, the plugin automatically forwards a hello-world.action request to /WEB-INF/content/hello-world.jsp even if no HelloWorld.java is defined.

Please see http://struts.apache.org/release/2.1.x/docs/convention-plugin.html for that.

On the other hand, we put JSP files under WEB-INF to avoid any direct access to JSP files.

I think this behavior of convention plugin ruins JSP access policy. Any one can make a direct access to a JSP by simply calling a, build on the fly, action.

Am I correct?! If yes, can we disable this feature?

Answer 1

No, you are not quite correct. The pages have not direct access if they are under WEB-INF. The convention plugin creates additional to XML based configuration from the Action classes by convention. So, you have access only to results returned by those actions. The convention plugin places its configuration under the XWork package as described in the docs and this answer. So, resolving conflicts, which is possible if you don't specify a parent package. You can also use convention annotations to customize the generated configuration. The convention plugin by default scans for classes under the base package, which could be struts or actions that is configurable and have Action suffix. These are all default configuration for convention plugin. If you'd like to change the default settings you could use a constant tag in struts.xml or corresponding properties in struts.properties.

However, the documentation is not clear about how it handles

actionless results that is identified by the URL

Also, is not clear what URL is used to identify it. I think you are already familiar with actionless configuration, where you can return result SUCCESS without action execution, because the action class is used by default. But, the problem even is not here. The convention plugin along with configuration it creates mentioned above also put an unknown handler which should handle URLs for which a configuration is not exist (i.e. not created by the convention). This is the source of the problem. The plugin also doesn't allow to replace/override the configuration. Happily, there's unknown handler manager (that could be replaced if needed) who is handled unknown actions via iteration of "unknown-handler-stack", that is managed by this manager. With the handler stack you could configure the order in which unknown handlers are iterated. Note, the loop ends when an action config is returned by the handler. This means if you create your own unknown handler and set the order in the stack then convention handler could be bypassed.
.