On 24/02/2014 02:10, Greg Wilkins 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, > > 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 own view is that I'm happy to look at each of the issues you raise. I'd like the Tomcat code to be easy to re-use by other folks so if there are changes we can make that simplify this then I am in favour of those. That said, there is a balance to be struck. If the changes are very invasive or impact performance then I'd be less likely to support them. > 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: Are we just talking about Tomcat 8 here? > - 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? Discoverable in the Commons Logging sense of the term is not something I am a fan of. At the risk of opening a huge can of worms would now be a good time to review the choice to implement JULI? There have been some significant changes in the Java logging landscape since then. Would now be a good time to switch to log4j2, slf4j, something else? How would such a switch impact potential downstream users like Jetty? > - 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? The InstanceManagerFactory was intended to provide downstream users with a way of injecting their own InstanceManager into Jasper. Is that not sufficient? If not, what would you like to change? > - 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. If I am looking at the right commit on GitHub, that change looks reasonable to me. > - 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. No objections to this in principle. > - We would also like to add the META-INF magic to make the resulting > jars more OSGi consumable. +1 See https://issues.apache.org/bugzilla/show_bug.cgi?id=52381 I'm more than happy to see the necessary OSGi info go into the JARs. What has been missing to date is an automated way to make this happen. No-one in the Tomcat devs appears to have the knowledge of a) what is required and b) how it might be auto-generated. The offers of help so far have revolved around using Maven and while we do us Maven to upload JARs to Nexus and from there to Maven central, the actual building is done with Ant. > 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). Sounds good to me. > 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. Now is the time to do this before 8.0.x becomes stable. > 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? As long as a diff arrives in a format we can review it, it doesn't really matter how that diff is generated or how it reaches is. Pull requests should be fine. We need to get infra to hook them up to our dev list. I'll try and create that request today. If we don't notice a PR after a few days feel free to ping us on the dev list. If anyone from Jetty is going to be at ApacheCon, we are holding a Tomcat Summit on the Friday. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
