[jira] [Created] (TILES-597) Eliminate the need for deploying pre-compiled JSP files in the WAR when using OptionsRenderer

["Jo Schm (JIRA)" <ji...@apache.org>]

Jo Schm created TILES-597:
-----------------------------

             Summary: Eliminate the need for deploying pre-compiled JSP files in the WAR when using OptionsRenderer 
                 Key: TILES-597
                 URL: https://issues.apache.org/jira/browse/TILES-597
             Project: Tiles
          Issue Type: Improvement
          Components: tiles-extras
    Affects Versions: 3.0.5
            Reporter: Jo Schm


*Background*:

When pre-compiling JSPs on Tomcat the resulting servlet classes are stored inside the WAR in a directory, e.g. "${webapp.path}/WEB-INF/classes/org/apache/jsp". Additionally a "generated_web.xml" containing their servlet-mappings is produced and merged with "web.xml", thus making the Container dispatch requests for a pre-compiled JSP to the proper servlet directly rather than targeting the JspServlet.

Example of such a request:
{code:java}
requestDispatcher.forward("/WEB-INF/bar.jsp"){code}
Therefore: If "foo.jsp" had been pre-compiled it would be no longer needed to include the .jsp file in the WAR, since the compiled servlet class would already be available. In fact, this is how in our project we would like to build the WAR file, since we do not want to include resources that are not being used.

*Problem in OptionsRenderer:*

However this causes an exception thrown by OptionsRenderer similar to
{code:java}
java.io.IOException: None of the options existed for /WEB-INF/{options[searchPaths]}/bar.jsp {code}
, since OptionsRenderer's check for existence of an option merely relies on the existence of the JSP file.

Please consider extending the check for existence of an option: Maybe this could be achieved by additionally checking if a servlet-mapping exists for the given JSP Path. In case of pre-compiled JSPs these mappings come from the "generated_web.xml" and should be available through ServletContext.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)