On Feb 23, 2014, at 5:55 PM, Greg Wilkins <gr...@apache.org> wrote: > On Jun 26, 2013, at 05:44:23 GMT Jeremy Boynes <jboy...@apache.org> wrote: > >> 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). > > > Jeremy et al,
Hi Greg, > > The Jetty project has been considering switching to directly consume the > apache version of Jasper JSP. > > However, there are some tomcat dependencies in jasper that means we cannot > directly consume the jar produced by the apache project. We had assumed > that there would be little interest here to make jasper separable so we had > begun our own effort at github. However, when I gave a heads up to > priv...@tomcat.apache.org, I was pointed at Jeremy's email. So if > there is some interest here, then it would definitely be better to do this > within apache rather than via an intermediate repository. My original interest was partly academic in that Servlet 3.0 implies the JSP engine should be pluggable and I was wondering if it actually could. I was also interested in where we could take the JSP engine in light of other developments in server-side template engines especially the JavaScript-based ones (e.g. Handlebars, Dust). I hadn’t originally envisioned Jetty picking this up but would be happy to help. The work I’ve done to date has all been in trunk (Tomcat 8.x) and IMO is disruptive enough that it would not be wise to attempt a back port into Tomcat 7.x. It focused on decoupling Catalina from Jasper i.e. removing any need for Jasper-specific initialization in Catalina. I think that is mostly complete, with Jasper’s SCI now handling bootstrap of the JSP engine. There is still some work to do setting up the JSP servlet (the *.jsp[x] mapping) as in Tomcat that is defined by the default web.xml. It would be easy enough for the SCI to register a servlet and mapping but Jasper would ideally have a configuration mechanism for it that does not require modification to container or application web.xml files. > What we have done so far is to create a github project at github: > https://github.com/jetty-project/jasper-jsp. This project mounts the > tomcat github repo as a subtree and removes everything that is not el, > jasper or a used utility. We've then changed a few hard tomcat > dependencies to produce a container neutral version of jasper, which we > then consume and specialise within a build of the jetty project (not yet at > eclipse). We have this working at the moment, but have not yet done any > releases, so there are no indelible maven artefacts yet. Nor have we done > the IP clearance work to officially consume such an artefact within the > eclipse project. I’ve not had a chance to take a look yet but will this evening. > > The changes that we made to make jasper neutral were: > > - Modified JuliLog LogFactory to use a ServiceLoader to find an > implementation of Log. Within the jetty project we add an impl of the Juli > Log that logs to the jetty log and we set that as a service in our own jars > META-INF. Note that judging by some of the comments in the classes, there > is not much desire to make logging discoverable? > - We have replaced the InstanceManager with a pretty simple > non-container version. It does not do post construct or pre destroy, but > don't think these are needed for Jasper. I guess rather than replace the > top level InstanceManager, it would be better to have a Jasper Instance > manager that could be instantiated as the container specific version, > perhaps also with a ServiceLoader? I thought pre- and post- construct were now necessary parts of tag lifecycle? This seemed to me to be one of the areas where the Servlet API was lacking. It provides bean factories for the Servlet components but does not make a general-purpose bean factory available to frameworks like JSP. In a JavaEE world with CDI available, I think Jasper could use the CDI BeanFactory to create JSP-servlet and tag instances but that is not something available in a standalone Servlet environment. > - We changed the jasper ServletContainerInitialiser to allow some > pluggability of the scanner and we turned off ServiceLoader for it so that > we can provide our own extension of it. > - We made the Tld scanning check for a prescanned list so that we can do > the TLD discovery in our own scanning (rather than do another scan) and > push those into jasper. A neutral version of Jasper could make scanning > container specific and then most of the dependencies on tomcat utils could > be removed. Sounds good. There are several cases where frameworks would benefit from scan results, and the number of times different frameworks scan the classpath/war is becoming an issue. I thought there was a JSR for a common scanning mechanism but I don’t remember if it went anywhere; if it’s dead, what do you think about a common scan SPI for frameworks? > - We would also like to add the META-INF magic to make the resulting > jars more OSGi consumable. > > As a project, Jetty has no desire to fork jasper. Rather we just want to > re-bundle it in a way that can be consumed by the jetty project at eclipse > and to use our own sanning/discovery/configuration mechanisms. We wish to > be bug for bug compatible and if we did find/fix a bug, our preference > would be to contribute back to apache. Also happy to contribute back > changes to improve start time (eg by avoiding duplicate jar scans). > > We totally understand that making jasper consumable by jetty will not be a > high priority for the tomcat project and that even minor changes to jar > packaging can be disruptive. However, if it is desirable for other reasons, > then we'd certainly be keen to lend a hand and I think most(all?) of our > committers are already apache committers on some project or other. > > Anyway, we'll hold off making any indelible maven artefacts from our github > project for a while, so that if something does happen within apache we can > erase what we have done already. > > If there is interest here, then we could prepare a git pull request of our > changes (against the apache github clone), or would we need to remember our > svn and submit a diff against that? There was a thread a while ago on moving Tomcat to Git as its primary repo. Cheers Jeremy
signature.asc
Description: Message signed with OpenPGP using GPGMail
