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, 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. 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. 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? - 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. - 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? cheers
