tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: Jasper Improvements
Date Mon, 24 Feb 2014 01:55:36 GMT
On Jun 26, 2013, at 05:44:23 GMT Jeremy Boynes <> 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
> 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, 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:     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?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message