On Jun 26, 2013, at 12:10 PM, Nick Williams <nicho...@nicholaswilliams.net> wrote:
> > On Jun 26, 2013, at 1:57 PM, Jeremy Boynes wrote: > >> 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. > > A word of caution: I don't think web.xml-less compilation is possible. > web.xml /and/ web-fragment.xml can contain <jsp-config>, which sets up rules > surrounding how JSPs are compiled. Before a single JSP in an application can > be compiled, the deployment descriptor and all web fragments must be > processed and merged so that the JSP configuration can be taken into > consideration during compilation. This requires a large portion of the > application (you need WEB-INF/web.xml and WEB-INF/lib). Could we do this with two different modes: one for a fully assembled web application, the other for a standalone JSP web fragment? In fully-assembled mode users would assemble their fragments with the JSP source in META-INF/resources and then compilation would happen using the context of the fully assembled application. This is what we have today, only instead of Jasper needing the container to provide a synthetic web.xml as an attribute it gets all of its information from the ServletContext as described in section 8.3 of the spec. All the merging is handled by the ServletContainer and is available through getJspConfigDescriptor(). When run in this mode outside a container, the setup part of the Ant Task would need to mimic a full ServletContext including the merging etc. which I don't believe it does today (i.e. JspC does not pre-compile JSP resources in web fragment jars, only those in the final webapp). We could potentially reuse that logic from Catalina rather than replicate it. Standalone JSP web fragment mode on the other hand would allow users to pre-compile JSPs into a library jar that would appear to the assembler/container as one containing Servlets rather than JSPs (described by a web-fragment.xml or @WebServlet annotations). Assembly is different to above as it is happening based on binary classes rather than JSP source. The effect of that is that the provider here is able to set the own JSP settings and not have them impacted by settings of the final assembly. This mimics today's behaviour when JspC is run against a fragment project where it uses the web.xml supplied at build time for that fragment. For this to work we would need to add options to JspC to allow the context to be defined as the fragment source would not itself contain a WEB-INF. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
