On Jun 26, 2013, at 7:49 AM, Christopher Schultz <ch...@christopherschultz.net> wrote:
> Jeremy, > > On 6/26/13 1:44 AM, Jeremy Boynes wrote: >> On Jun 11, 2013, at 1:50 PM, Nick Williams >> <nicho...@nicholaswilliams.net> wrote: >>> >>> Okay. One of many reasons I ask is that I still have it on my to-do >>> to make some improvements on the JSP compiler to support things >>> like 1) precompiling all JSPs on deploy and 2) a better Ant task. I >>> don't know how much the EL changes might affect this JSP >>> compilation (hopefully it's fairly decoupled), and I'd like that to >>> not seriously hinder any effort to back-port my improvements to >>> Tomcat 7. I'm wondering if this needs to move higher on my list and >>> get in before the EL changes. Any insight? >> >> I have been thinking about improvements to Jasper as well around >> better support for Servlet 3.0 concepts. One area would be decoupling >> it from Tomcat, bootstrapping using an SCI as hinted in >> ContextConfig. I'd also be interested in improving the Ant task as >> well, such as support for pre-compiling a separate package that would >> be treated as a web fragment (including web.xml-less pre-compilation, >> generating a web-fragment.xml rather than a web.xml snippet or >> potentially eliminating the XML entirely if the generated code can be >> annotated with @WebServlet). > > https://issues.apache.org/bugzilla/show_bug.cgi?id=50234 > > I tried some forays into this a few years ago, but got stuck in the > confusion of how everything works together. I wanted to do something > simple like get the web-app's spec-version number, but could not figure > out how to do it. I find usage and implementation very confusing as well - an example being things that can be configured on the Task vs. init-params for the JSP servlet vs. things set via system properties. A challenge here is that cleaning it up would likely warrant incompatible changes so would be out for 7.x but potentially possible for 8.x - I'd be interested in what people think about a major refactor that allowed incompatible changes (assuming they were justified not arbitrary). You wrote in the bug that "annotation's don't make sense" - could you clarify that? I was thinking that we could have Jasper add @WebServlet("/foo.jsp") to the class generated for "foo.jsp" and then that would be picked up by a container as part of its normal scan. We could also have an SCI @HandlesTypes(JspPage.class) and then register the JSP servlets itself but two issues come to mind: 1) the need for metadata that duplicates what the normal servlet annotations could convey 2) avoiding conflicts with classes that are bound via jsp-property-group or servlet-mapping elements in XML descriptors What happens to a fragment compiled a build-time whose properties differ from those in the final runtime (for example, due to settings resulting from a merged web.xml)? One option would be to say that the build process had simply converted all the JSPs into a jar-full of Servlets and that they should be deployed as such; if the user wants them treated as JSPs they should be packaged as such into META-INF/resources. How should we control pre-compile on deploy? The spec already supports if the web.xml contains a <servlet> entry with a <jsp-file> and <load-on-startup> but that requires defining a entry for every individual JSP ("jsp-file element contains the full path to *a* JSP file" on pp 14-160) which is a pain. We could embed an Ant task in a configuration file (e.g. META-INF/jasper.xml) but that adds a dependency on Ant and seems like overkill. Alternatively we can have the SCI read the configuration file and do the necessary. If we go the SCI route, we could also define a JspConfiguration annotation or interface that a user could place on a class they want to handle initialization. The SCI could @HandlesTypes that, calling it to handle user-provided initialization. We could expose the translator and compiler interfaces so it can handle pre-compilation; we could refactor the JSPServlet to use them in the same way. Cheers Jeremy BTW, can't we use ServletContext#getEffectiveMajorVersion() to determine the spec-version number? --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
