Re: TldScanner + Config, was: Jasper Improvements
On Feb 27, 2014, at 4:09 AM, Konstantin Kolinko wrote: > 2014-02-27 10:17 GMT+04:00 Jeremy Boynes : >> >> I was thinking of supporting compile-on-start as a option where the >> initializer would scan the war for JSP(x) files and initiate the compilation >> during startup. This was intended for production use where use of JspC was >> not practical (e.g. because the actual version of runtime is not known at >> pre-compilation time) but where taking a hit on access would be undesirable. > > http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html > -> "Background JSP compilation" > > Compiling can take notable time, so I think it wouldn't be good to > delay application startup for that time. I had in mind a production configuration where the JSPs are not expected to change between deployments. IIRC, background compilation only works with JSPs that have already been hit so there is still a compilation delay on first touch. This adds jitter to the latency timings for an application. The idea was to avoid that by compiling everything during startup before the application starts taking live traffic. As you say, this would slow startup down but (assuming multiple hosts or parallel deployment) would not impact user requests. A variation would be to kick off a background task so that startup is not delayed. > >> I was thinking there to combine the TLD and JSP scans into one. > > Those are different scans. > For TLDs you have to scan jar files. > For JSPs you have to scan application resources. TldScanner#scanResourcePaths has to scan all application resources under /WEB-INF as well. For a MVC-style application where the JSPs are under /WEB-INF there can be substantial overlap. — Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
Re: TldScanner + Config, was: Jasper Improvements
2014-02-27 10:17 GMT+04:00 Jeremy Boynes : > > I was thinking of supporting compile-on-start as a option where the > initializer would scan the war for JSP(x) files and initiate the compilation > during startup. This was intended for production use where use of JspC was > not practical (e.g. because the actual version of runtime is not known at > pre-compilation time) but where taking a hit on access would be undesirable. http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html -> "Background JSP compilation" Compiling can take notable time, so I think it wouldn't be good to delay application startup for that time. > I was thinking there to combine the TLD and JSP scans into one. Those are different scans. For TLDs you have to scan jar files. For JSPs you have to scan application resources. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
TldScanner + Config, was: Jasper Improvements
On Feb 26, 2014, at 4:55 PM, Greg Wilkins wrote: > Just in case it was missed, here is the pull request I generated: > > https://github.com/apache/tomcat/pull/4 > > Happy to talk about individual changes either in the comments there or here. Related to the TldScanner changes, I’m assuming you have some integration code in Jetty that is sub-classing the initializer and overriding newTldScanner? I was thinking of supporting compile-on-start as a option where the initializer would scan the war for JSP(x) files and initiate the compilation during startup. This was intended for production use where use of JspC was not practical (e.g. because the actual version of runtime is not known at pre-compilation time) but where taking a hit on access would be undesirable. I was thinking there to combine the TLD and JSP scans into one. There may be other reasons to scan e.g. looking for tag-plugins packaged in jars (no XML config needed a bit like a Tld). We also have an issue where Jasper is very reliant on system properties and the Options built from the init-params of JspServlet. In short, I’m wondering if instead of the subclassing we define a JasperConfiguration interface and have the initializer look for an instance of it in a context attribute. The configuration there would allow the container to replace parts of Jasper’s initialization (e.g. by supplying a Collection of pre-scanned TLDs, by identifying TLDs "provided by the container” etc.) and other configuration on a per-context basis. Would something like that work for you? Cheers Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Jasper Improvements
Just in case it was missed, here is the pull request I generated: https://github.com/apache/tomcat/pull/4 Happy to talk about individual changes either in the comments there or here. cheers On 27 February 2014 09:24, Greg Wilkins wrote: > > On 25 February 2014 17:04, Violeta Georgieva wrote: > >> We should be very careful when adding the OSGi meta data to the tomcat >> artifacts. Something that is stopping me from adding it right now, is that >> the different projects add different OSGi meta data specific to the >> concrete project. For example I don't think that the way that is used in >> Gemini Web/Virgo is sufficient for Jetty. >> > > From a Jetty point of view, if the apache project puts in OSGi meta data > suitable for consumption by Gemini Web/Virgo, then we'd look at changing > how we consume JSP in OSGi to use the same meta data.If it is not > sufficient for us, then that's our problem and we'll deal with it > externally. > > cheers > > > -- > Greg Wilkins > http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that > scales > http://www.webtide.com advice and support for jetty and cometd. > -- Greg Wilkins http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Re: Jasper Improvements
On 25 February 2014 17:04, Violeta Georgieva wrote: > We should be very careful when adding the OSGi meta data to the tomcat > artifacts. Something that is stopping me from adding it right now, is that > the different projects add different OSGi meta data specific to the > concrete project. For example I don't think that the way that is used in > Gemini Web/Virgo is sufficient for Jetty. > >From a Jetty point of view, if the apache project puts in OSGi meta data suitable for consumption by Gemini Web/Virgo, then we'd look at changing how we consume JSP in OSGi to use the same meta data.If it is not sufficient for us, then that's our problem and we'll deal with it externally. cheers -- Greg Wilkins http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Re: Jasper Improvements
Hi Greg, 2014-02-24 3:55 GMT+02:00 Greg Wilkins : > > 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 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. We should be very careful when adding the OSGi meta data to the tomcat artifacts. Something that is stopping me from adding it right now, is that the different projects add different OSGi meta data specific to the concrete project. For example I don't think that the way that is used in Gemini Web/Virgo is sufficient for Jetty. Regards Violeta > 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
RE: Jasper Improvements
> From: Greg Wilkins [mailto:gr...@intalio.com] > Subject: Re: Jasper Improvements > isn't there a golden rule that no problem cannot be solved > without another layer of delegation? David Wheeler: "All problems in computer science can be solved by another level of indirection." Kevlin Henney: "...except for the problem of too many layers of indirection." Also look at RFC 1925. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper Improvements
On 24 February 2014 22:48, Mark Thomas wrote: > On 24/02/2014 02:10, Greg Wilkins wrote: > > The Jetty project has been considering switching to directly consume the > > apache version of Jasper JSP. > 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. > +1. Totally understand that only changes that make sense for the whole project should be pushed back. Even if it is not 100% of what we need, if it is close we might be able to consume by repackaging apache jars rather than rebuilding. > Are we just talking about Tomcat 8 here? > > For our part yes. We are only doing this for new releases and not back porting. > >- 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? > I'm always amazed at how hard logging is for projects like ours that have to work with everybody else's logging expectations. At Jetty, we've chosen not to use any common logging framework, but to have a thin facade over stderr or slf4j - more or less what you've done with Juli. I know this can end up with a facade over a facade over a facade over a logging framework, but isn't there a golden rule that no problem cannot be solved without another layer of delegation? For us working with however you make Juli pluggable (even if it is replacing the LogFactory class), will be easier than if you pick a specific framework. > > 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? > Hmm will review that again and get back to you. > 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. > We'll prepare some PR in the next week. > If anyone from Jetty is going to be at ApacheCon, we are holding a > Tomcat Summit on the Friday. > I don't think so this year. thanks for your consideration. -- Greg Wilkins http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Re: Jasper Improvements
On Feb 23, 2014, at 5:55 PM, Greg Wilkins wrote: > 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 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 m
Re: Jasper Improvements
On 24/02/2014 02:10, Greg Wilkins wrote: > 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 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 hav
Re: Jasper Improvements
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 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 -- Greg Wilkins
Re: Jasper Improvements
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 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
Re: Jasper improvements - web resources and TLDs
On Aug 12, 2013, at 8:40 AM, Mark Thomas wrote: > On 12/08/2013 16:20, Jeremy Boynes wrote: > > I'm wondering about adding enableWebSockets() and enableJSPs() methods > to Tomcat which would automatically add the relevant SCI to any Context > created via one of the addContext(...) methods. Thoughts? I'm torn on this. On the up side, this would be a simple way to enable a specific feature. On the down side it would mean Catalina would need to know about features' SCIs which is adding coupling. An embedder would need to have added the JARs for the feature to the classpath at some point so how about just adding a loadServletContainerInitializers() method which would trigger the same discovery process ContextConfig was using? -- Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Jasper improvements - web resources and TLDs
2013/8/12 Mark Thomas wrote: > > > I'm wondering about adding enableWebSockets() and enableJSPs() methods > to Tomcat which would automatically add the relevant SCI to any Context > created via one of the addContext(...) methods. Thoughts? > +1
Re: Jasper improvements - web resources and TLDs
On 12/08/2013 16:20, Jeremy Boynes wrote: > On Aug 12, 2013, at 7:46 AM, Mark Thomas wrote: > >> On 10/08/2013 23:20, Jeremy Boynes wrote: >>> On Jul 22, 2013, at 10:10 AM, Mark Thomas >>> wrote: >>> On 21/07/2013 18:36, Jeremy Boynes wrote: ... > In the meantime, I'm going to look at refactoring the TLD > support as described above. Nice. See my note about TLD processing in the TOMCAT-NEXT.txt file in the root on trunk. >> >> Don't forget the above :) > > Not forgotten, just a work in progress :) > >> >>> I've taken the first step on this in >>> http://svn.apache.org/r1512826 which moves the TLD processing >>> from TldConfig into Jasper's ServletContainerInitializer. There >>> are a couple of implications for this: 1) Jasper's SCI needs to >>> be activated to use TLDs This should cause no impact when >>> ContextConfig is used to configure a web application in the >>> normal way is Jasper is on the class path. When using Context >>> directly in embedded mode, JasperInitializer now need to be added >>> to enable JSP functionality which will automatically TLD >>> processing to add listeners. Previously, TLDs would be scanned >>> automatically unless the processTld property on StandardContext >>> was explicitly set false. IOW, TLDs will only be processed if JSP >>> functionality is added, and don't need to be turned off if it is >>> not. >> >> Isn't the SCI discovered if Jasper is on the classpath when running >> in embedded mode? If not, do we know why not? > > The SCI will be discovered if the embedder adds an application as > that runs ContextConfig which does the scan. However, if they > construct the context directly (without running ContextConfig) they > will need to make sure the SCI is added to use JSP functionality. > This is slightly different to now where TldConfig would scan for and > add listeners from TLDs even if Jasper was not on the classpath > (TldConfig would be added by StandardContext's initInternal method > unless explicitly disabled by setting processTlds false). IMO, the > new behaviour maintains a cleaner separation as it means embedders > just using Servlet functionality are not impacted by JSP-related > features. > > There was one test case where we added a context directly but used > JSPs. I had to add the SCI for that one. All other tests using the > embedded server were fine. Thanks for clarifying this. I'm wondering about adding enableWebSockets() and enableJSPs() methods to Tomcat which would automatically add the relevant SCI to any Context created via one of the addContext(...) methods. Thoughts? >>> 2) As part of the change for processTlds I deprecated the >>> operations on Context to set/get TLD processing properties (for >>> validation and namespace) as they are can't be used by Jasper's >>> SCI. If there are no objections to an API change at this stage I >>> will go ahead and remove them completely. XML validation for TLDs >>> can now be controlled via the >>> "org.apache.jasper.validateDescriptors" initParam for the >>> ServletContext; namespace processing is always on as we require >>> >3.0 (due to the SCI etc.) which uses namespaces anyway >> >> Remove them. At this point in Tomcat 8 we should be removing >> anything that is no longer used. > > Will do. When I do that I'll also add the "removed in 8" deprecation > warnings to tc7.0.x. Great. >> On a related note, I am now seeing a number of warnings about using >> a deprecated API. It looks like this is because Jasper is still >> using the old code. What is the timescale for switching Jasper to >> use the SCI? > > I would estimate the next week or so depending on real-world > commitments (aka work). I can remove the deprecation tags in trunk if > that would help. No need to remove the deprecation warnings. I would like to get 8.0.0-RC2 tagged in about the same sort of timeframe (I have some non-blocking IO issues to fix first) and it would be good although not necessary to get this finished by then. >>> 3) TldScanner parses TLDs as it goes creating a cache of parsed >>> values keyed off TLD URI. It should probably create a second >>> mapping from "TLD resource path" to the parse result in order to >>> handle taglib directives that specify paths. I'll look at that >>> when refactoring the Jasper side. That will also allow the second >>> scan to be removed. >> >> This is touched upon in the TOMCAT-NEXT.txt file. > > I managed to add more in this area after sending this, splitting the > scan results and removing the second scan. The next step is to retain > the TLD content loaded during the scan to pre-load a cache to avoid > reloading each TLD every time a JSP is translated. That will need > stronger dependency tracking to invalidate entries if TLDs or tag > files change. It will take me a while though to figure out the code > around TagLibraryInfoImpl as it's a bit convoluted. If you think it is bad now... :) I appreciate the problem. I spent a long time refacto
Re: Jasper improvements - web resources and TLDs
On Aug 12, 2013, at 7:46 AM, Mark Thomas wrote: > On 10/08/2013 23:20, Jeremy Boynes wrote: >> On Jul 22, 2013, at 10:10 AM, Mark Thomas wrote: >> >>> On 21/07/2013 18:36, Jeremy Boynes wrote: >>> ... In the meantime, I'm going to look at refactoring the TLD support as described above. >>> >>> Nice. See my note about TLD processing in the TOMCAT-NEXT.txt file in >>> the root on trunk. > > Don't forget the above :) Not forgotten, just a work in progress :) > >> I've taken the first step on this in >> http://svn.apache.org/r1512826 >> which moves the TLD processing from TldConfig into Jasper's >> ServletContainerInitializer. There are a couple of implications for this: >> 1) Jasper's SCI needs to be activated to use TLDs >> This should cause no impact when ContextConfig is used to configure a web >> application in the normal way is Jasper is on the >> class path. When using Context directly in embedded mode, >> JasperInitializer now need to be added to enable JSP functionality >> which will automatically TLD processing to add listeners. Previously, TLDs >> would be scanned automatically unless the processTld >> property on StandardContext was explicitly set false. IOW, TLDs will only >> be processed if JSP functionality is added, and >> don't need to be turned off if it is not. > > Isn't the SCI discovered if Jasper is on the classpath when running in > embedded mode? If not, do we know why not? The SCI will be discovered if the embedder adds an application as that runs ContextConfig which does the scan. However, if they construct the context directly (without running ContextConfig) they will need to make sure the SCI is added to use JSP functionality. This is slightly different to now where TldConfig would scan for and add listeners from TLDs even if Jasper was not on the classpath (TldConfig would be added by StandardContext's initInternal method unless explicitly disabled by setting processTlds false). IMO, the new behaviour maintains a cleaner separation as it means embedders just using Servlet functionality are not impacted by JSP-related features. There was one test case where we added a context directly but used JSPs. I had to add the SCI for that one. All other tests using the embedded server were fine. > >> 2) As part of the change for processTlds I deprecated the operations on >> Context to set/get TLD processing properties (for >> validation and namespace) as they are can't be used by Jasper's SCI. If >> there are no objections to an API change >> at this stage I will go ahead and remove them completely. XML validation >> for TLDs can now be controlled via the >> "org.apache.jasper.validateDescriptors" initParam for the ServletContext; >> namespace processing is always on as we >> require >3.0 (due to the SCI etc.) which uses namespaces anyway > > Remove them. At this point in Tomcat 8 we should be removing anything > that is no longer used. Will do. When I do that I'll also add the "removed in 8" deprecation warnings to tc7.0.x. > > On a related note, I am now seeing a number of warnings about using a > deprecated API. It looks like this is because Jasper is still using the > old code. What is the timescale for switching Jasper to use the SCI? I would estimate the next week or so depending on real-world commitments (aka work). I can remove the deprecation tags in trunk if that would help. > >> 3) TldScanner parses TLDs as it goes creating a cache of parsed values keyed >> off TLD URI. It should probably create a second >> mapping from "TLD resource path" to the parse result in order to handle >> taglib directives that specify paths. I'll look at >> that when refactoring the Jasper side. That will also allow the second >> scan to be removed. > > This is touched upon in the TOMCAT-NEXT.txt file. I managed to add more in this area after sending this, splitting the scan results and removing the second scan. The next step is to retain the TLD content loaded during the scan to pre-load a cache to avoid reloading each TLD every time a JSP is translated. That will need stronger dependency tracking to invalidate entries if TLDs or tag files change. It will take me a while though to figure out the code around TagLibraryInfoImpl as it's a bit convoluted. Cheers Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Jasper improvements - web resources and TLDs
On 10/08/2013 23:20, Jeremy Boynes wrote: > On Jul 22, 2013, at 10:10 AM, Mark Thomas wrote: > >> On 21/07/2013 18:36, Jeremy Boynes wrote: >> ... >>> In the meantime, I'm going to look at refactoring the TLD support as >>> described above. >> >> Nice. See my note about TLD processing in the TOMCAT-NEXT.txt file in >> the root on trunk. Don't forget the above :) > I've taken the first step on this in > http://svn.apache.org/r1512826 > which moves the TLD processing from TldConfig into Jasper's > ServletContainerInitializer. There are a couple of implications for this: > 1) Jasper's SCI needs to be activated to use TLDs >This should cause no impact when ContextConfig is used to configure a web > application in the normal way is Jasper is on the >class path. When using Context directly in embedded mode, > JasperInitializer now need to be added to enable JSP functionality >which will automatically TLD processing to add listeners. Previously, TLDs > would be scanned automatically unless the processTld >property on StandardContext was explicitly set false. IOW, TLDs will only > be processed if JSP functionality is added, and >don't need to be turned off if it is not. Isn't the SCI discovered if Jasper is on the classpath when running in embedded mode? If not, do we know why not? > 2) As part of the change for processTlds I deprecated the operations on > Context to set/get TLD processing properties (for >validation and namespace) as they are can't be used by Jasper's SCI. If > there are no objections to an API change >at this stage I will go ahead and remove them completely. XML validation > for TLDs can now be controlled via the >"org.apache.jasper.validateDescriptors" initParam for the ServletContext; > namespace processing is always on as we >require >3.0 (due to the SCI etc.) which uses namespaces anyway Remove them. At this point in Tomcat 8 we should be removing anything that is no longer used. On a related note, I am now seeing a number of warnings about using a deprecated API. It looks like this is because Jasper is still using the old code. What is the timescale for switching Jasper to use the SCI? > 3) TldScanner parses TLDs as it goes creating a cache of parsed values keyed > off TLD URI. It should probably create a second >mapping from "TLD resource path" to the parse result in order to handle > taglib directives that specify paths. I'll look at >that when refactoring the Jasper side. That will also allow the second > scan to be removed. This is touched upon in the TOMCAT-NEXT.txt file. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements - web resources and TLDs
On Jul 22, 2013, at 10:10 AM, Mark Thomas wrote: > On 21/07/2013 18:36, Jeremy Boynes wrote: > ... >> In the meantime, I'm going to look at refactoring the TLD support as >> described above. > > Nice. See my note about TLD processing in the TOMCAT-NEXT.txt file in > the root on trunk. I've taken the first step on this in http://svn.apache.org/r1512826 which moves the TLD processing from TldConfig into Jasper's ServletContainerInitializer. There are a couple of implications for this: 1) Jasper's SCI needs to be activated to use TLDs This should cause no impact when ContextConfig is used to configure a web application in the normal way is Jasper is on the class path. When using Context directly in embedded mode, JasperInitializer now need to be added to enable JSP functionality which will automatically TLD processing to add listeners. Previously, TLDs would be scanned automatically unless the processTld property on StandardContext was explicitly set false. IOW, TLDs will only be processed if JSP functionality is added, and don't need to be turned off if it is not. 2) As part of the change for processTlds I deprecated the operations on Context to set/get TLD processing properties (for validation and namespace) as they are can't be used by Jasper's SCI. If there are no objections to an API change at this stage I will go ahead and remove them completely. XML validation for TLDs can now be controlled via the "org.apache.jasper.validateDescriptors" initParam for the ServletContext; namespace processing is always on as we require >3.0 (due to the SCI etc.) which uses namespaces anyway 3) TldScanner parses TLDs as it goes creating a cache of parsed values keyed off TLD URI. It should probably create a second mapping from "TLD resource path" to the parse result in order to handle taglib directives that specify paths. I'll look at that when refactoring the Jasper side. That will also allow the second scan to be removed. Cheers Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Jasper improvements/XML handling
Jeremy, A little late returning to the party... On 7/8/13 1:38 AM, Jeremy Boynes wrote: > Finally, Jasper parses these documents first into DOM and the into > its own version based on TreeNode (this is separate from the parse > tree used for actual JSPs). Jasper already depends on tomcat-util for > the JarScanner so could potentially use Digester for this in the same > way Catalina does. It would simplify the fragment merge logic in JspC > if it could reuse what was in Catalina's WebXml (something I'm > hacking around in 53737 right now). Alternatively, we could still > eliminate the intermediary DOM and TreeNode forms and use SAX or StAX > to parse directly into Jasper's objects - especially for TLDs where > it is using the spec's classes (TagLibraryInfo and TagInfo) as the > model. Any time you can use SAX instead of DOM without making the code too complicated, you should. -chris signature.asc Description: OpenPGP digital signature
Re: Jasper improvements - web resources and TLDs
On 21/07/2013 18:36, Jeremy Boynes wrote: > With r1505235 JspC is now merging in from web fragments. > It is still not handling resources found in those jars e.g. if they > are referenced by an include directive or from a prelude/coda > configuration. It also needs to compile any JSPs found as they could be accessed directly. > This should be handled through the ServletContext so > I'd suggest approaching it using the new webresource support. > However, that has dependencies on Catalina (e.g. Lifecycle) that JspC > would not need - how hard would that be to decouple? There is a lot of code there that JspC just doesn't need. I wonder if, at this stage, it would be simpler to just check each JAR for static resources and process any JSPs found. That balance might change once overlays are introduced but even then I suspect it won't. > In the meantime, I'm going to look at refactoring the TLD support as > described above. Nice. See my note about TLD processing in the TOMCAT-NEXT.txt file in the root on trunk. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements - web resources and TLDs
On Jul 8, 2013, at 12:23 AM, Mark Thomas wrote: > On 08/07/2013 06:38, Jeremy Boynes wrote: >> >> Another area of convergence is in parsing TLDs: currently both >> Catalina and Jasper do it, differently. > > A lot of the code is identical with large comments to keep the two > implementations in sync. > >> I believe Catalina only reads >> them to detect the Listeners they define and if that's the case we >> could perhaps add a SCI to Jasper that handled all TLD functionality >> including registering the listeners programmatically (at least that's >> what Servlet 8.3 implies). > > Agreed. > >> That would remove Catalina's dependency >> on web-jsptaglibrary*.xsd and on TLD-related classes. To support >> validation though we would need to add the XSD-based validation in >> Jasper. > > This is beginning to get far enough away from where the code is right > now that I'd suggest just noting the issue and come back to it when the > other changes are complete. With r1505235 JspC is now merging in from web fragments. It is still not handling resources found in those jars e.g. if they are referenced by an include directive or from a prelude/coda configuration. This should be handled through the ServletContext so I'd suggest approaching it using the new webresource support. However, that has dependencies on Catalina (e.g. Lifecycle) that JspC would not need - how hard would that be to decouple? In the meantime, I'm going to look at refactoring the TLD support as described above. Cheers Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements/XML handling
On Jul 8, 2013, at 2:32 PM, Mark Thomas wrote: > On 08/07/2013 16:02, Jeremy Boynes wrote: >> On Jul 8, 2013, at 12:23 AM, Mark Thomas wrote: >>> On 08/07/2013 06:38, Jeremy Boynes wrote: >> ... >>> I'm planning on merging these two patches and pressing on with a converged solution, but probably won't be able to do much until next weekend. >>> >>> I very much doubt that a single patch that did everything above would >>> ever get applied. Small incremental changes are the way to do this. I >>> think you've identified the key issues and the right order in which to >>> address them. Lets move forward but one small step at a time. >> >> Thanks. It sounds like a couple of people have looked into this area already >> and found a similar ball of twine. >> I'll start opening individual issues for the potential enhancements I found >> and break down the patches to be as fine grained as I can. > > Great. > > You've probably seen that I have started the work to move the web.xml > processing code to a common package. I'm validating each step by > comparing to Violetta's github version. > > trunk is going to be somewhat of a moving target over the next few days. > You'll probably see a few "It would be great if you could extract xyz > from your patch" requests but check trunk before you start on them as > they might already have been done by the time you read the message. For > example, the changes to the schema resolver are likely to be needed > fairly soon so that would be a good one to start with. Thanks, I'll start with that once I've caught up. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements/XML handling
On 08/07/2013 16:02, Jeremy Boynes wrote: > On Jul 8, 2013, at 12:23 AM, Mark Thomas wrote: >> On 08/07/2013 06:38, Jeremy Boynes wrote: > ... >> >>> I'm planning on merging these two patches and pressing on with a >>> converged solution, but probably won't be able to do much until next >>> weekend. >> >> I very much doubt that a single patch that did everything above would >> ever get applied. Small incremental changes are the way to do this. I >> think you've identified the key issues and the right order in which to >> address them. Lets move forward but one small step at a time. > > Thanks. It sounds like a couple of people have looked into this area already > and found a similar ball of twine. > I'll start opening individual issues for the potential enhancements I found > and break down the patches to be as fine grained as I can. Great. You've probably seen that I have started the work to move the web.xml processing code to a common package. I'm validating each step by comparing to Violetta's github version. trunk is going to be somewhat of a moving target over the next few days. You'll probably see a few "It would be great if you could extract xyz from your patch" requests but check trunk before you start on them as they might already have been done by the time you read the message. For example, the changes to the schema resolver are likely to be needed fairly soon so that would be a good one to start with. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements/XML handling
On 08/07/2013 16:55, Violeta Georgieva wrote: > 2013/7/8 Mark Thomas wrote: >> >> On 08/07/2013 06:38, Jeremy Boynes wrote: >>> On Jun 25, 2013, at 10:44 PM, Jeremy Boynes >>> wrote: >> >>> Jasper's descriptor parser (used for web.xml and TLDs) can only >>> validate DTD-based documents. I opened 55212 about adding it. Such a >>> fix could benefit from using the same resolver and cached copies that >>> Catalina does. This is less of an issue if Jasper uses the >>> ServletContext as it could rely on the container to parse/validate >>> web.xml. It would still be needed if we wanted JspC to validate files >>> standalone but there is a separate ant task that can do that. >> >> Jasper and Catalina need to share the same web.xml parsing and merging >> code. Violetta started on this before she was a committer but the work >> stalled primarily because of the size of patch which in turn was due to >> the re-factoring required. The first step is to get the parsing and >> merging into a package that can be shared by Jasper and Catalina. That >> is far easier for a committer to do as they can use the refactoring >> tools in an IDE rather than having to generate a huge patch and then >> wait for a committer to find the time to review it. >> > > > Jeremy, > > Here [1] is my work on the topic that I started several months ago. > We can discuss which parts of it are still applicable and I can work on > this also. > > Regards > Violeta > > [1] https://github.com/violetagg/apache-tomcat-8.0/commits/master Yep, that is where I was planning on starting from as well - at least following the same steps anyway. There may well be differences in the detail. One of the things I want to do is to take a look with Structure 101 to ensure that we get the interdependencies right. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements/XML handling
2013/7/8 Mark Thomas wrote: > > On 08/07/2013 06:38, Jeremy Boynes wrote: > > On Jun 25, 2013, at 10:44 PM, Jeremy Boynes > > wrote: > > > Jasper's descriptor parser (used for web.xml and TLDs) can only > > validate DTD-based documents. I opened 55212 about adding it. Such a > > fix could benefit from using the same resolver and cached copies that > > Catalina does. This is less of an issue if Jasper uses the > > ServletContext as it could rely on the container to parse/validate > > web.xml. It would still be needed if we wanted JspC to validate files > > standalone but there is a separate ant task that can do that. > > Jasper and Catalina need to share the same web.xml parsing and merging > code. Violetta started on this before she was a committer but the work > stalled primarily because of the size of patch which in turn was due to > the re-factoring required. The first step is to get the parsing and > merging into a package that can be shared by Jasper and Catalina. That > is far easier for a committer to do as they can use the refactoring > tools in an IDE rather than having to generate a huge patch and then > wait for a committer to find the time to review it. > Jeremy, Here [1] is my work on the topic that I started several months ago. We can discuss which parts of it are still applicable and I can work on this also. Regards Violeta [1] https://github.com/violetagg/apache-tomcat-8.0/commits/master
Re: Jasper improvements/XML handling
On Jul 8, 2013, at 12:23 AM, Mark Thomas wrote: > On 08/07/2013 06:38, Jeremy Boynes wrote: ... > >> I'm planning on merging these two patches and pressing on with a >> converged solution, but probably won't be able to do much until next >> weekend. > > I very much doubt that a single patch that did everything above would > ever get applied. Small incremental changes are the way to do this. I > think you've identified the key issues and the right order in which to > address them. Lets move forward but one small step at a time. Thanks. It sounds like a couple of people have looked into this area already and found a similar ball of twine. I'll start opening individual issues for the potential enhancements I found and break down the patches to be as fine grained as I can. Cheers Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements/XML handling
On 08/07/2013 06:38, Jeremy Boynes wrote: > On Jun 25, 2013, at 10:44 PM, 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. It was the intention of the Servlet EG that this should be possible. There are a number of areas where changes are required to make this work. I think you have identified the main ones. >> 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). My preference would be for the web-fragment.xml approach as I prefer having just a single file to look at when debugging. > I started on this and ended up with two patches that are converging. > For 55166 (which started out somewhere different), I have a patch to > update local entity handling in Catalina's XML parsing; for 53737, I > started to have Jasper's translator rely only on the ServletContext > and not need to parse merged web.xml XML passed as a ServletContext > attribute. These are converging in a few areas. Small, incremental changes are the way to go rather than one big patch. The larger the patch the less likely it is to get applied. I'd suggest getting the 55166 issues fixed first, then start looking at the larger problem of making Jasper rely solely on the Servlet API. > Jasper's descriptor parser (used for web.xml and TLDs) can only > validate DTD-based documents. I opened 55212 about adding it. Such a > fix could benefit from using the same resolver and cached copies that > Catalina does. This is less of an issue if Jasper uses the > ServletContext as it could rely on the container to parse/validate > web.xml. It would still be needed if we wanted JspC to validate files > standalone but there is a separate ant task that can do that. Jasper and Catalina need to share the same web.xml parsing and merging code. Violetta started on this before she was a committer but the work stalled primarily because of the size of patch which in turn was due to the re-factoring required. The first step is to get the parsing and merging into a package that can be shared by Jasper and Catalina. That is far easier for a committer to do as they can use the refactoring tools in an IDE rather than having to generate a huge patch and then wait for a committer to find the time to review it. > Another area of convergence is in parsing TLDs: currently both > Catalina and Jasper do it, differently. A lot of the code is identical with large comments to keep the two implementations in sync. > I believe Catalina only reads > them to detect the Listeners they define and if that's the case we > could perhaps add a SCI to Jasper that handled all TLD functionality > including registering the listeners programmatically (at least that's > what Servlet 8.3 implies). Agreed. > That would remove Catalina's dependency > on web-jsptaglibrary*.xsd and on TLD-related classes. To support > validation though we would need to add the XSD-based validation in > Jasper. This is beginning to get far enough away from where the code is right now that I'd suggest just noting the issue and come back to it when the other changes are complete. > Finally, Jasper parses these documents first into DOM and the into > its own version based on TreeNode (this is separate from the parse > tree used for actual JSPs). Jasper already depends on tomcat-util for > the JarScanner so could potentially use Digester for this in the same > way Catalina does. It would simplify the fragment merge logic in JspC > if it could reuse what was in Catalina's WebXml (something I'm > hacking around in 53737 right now). Alternatively, we could still > eliminate the intermediary DOM and TreeNode forms and use SAX or StAX > to parse directly into Jasper's objects - especially for TLDs where > it is using the spec's classes (TagLibraryInfo and TagInfo) as the > model. Again, I think this is looking too far ahead. > I'm planning on merging these two patches and pressing on with a > converged solution, but probably won't be able to do much until next > weekend. I very much doubt that a single patch that did everything above would ever get applied. Small incremental changes are the way to do this. I think you've identified the key issues and the right order in which to address them. Lets move forward but one small step at a time. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements/XML handling
On Jun 25, 2013, at 10:44 PM, 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 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). I started on this and ended up with two patches that are converging. For 55166 (which started out somewhere different), I have a patch to update local entity handling in Catalina's XML parsing; for 53737, I started to have Jasper's translator rely only on the ServletContext and not need to parse merged web.xml XML passed as a ServletContext attribute. These are converging in a few areas. Jasper's descriptor parser (used for web.xml and TLDs) can only validate DTD-based documents. I opened 55212 about adding it. Such a fix could benefit from using the same resolver and cached copies that Catalina does. This is less of an issue if Jasper uses the ServletContext as it could rely on the container to parse/validate web.xml. It would still be needed if we wanted JspC to validate files standalone but there is a separate ant task that can do that. Another area of convergence is in parsing TLDs: currently both Catalina and Jasper do it, differently. I believe Catalina only reads them to detect the Listeners they define and if that's the case we could perhaps add a SCI to Jasper that handled all TLD functionality including registering the listeners programmatically (at least that's what Servlet 8.3 implies) . That would remove Catalina's dependency on web-jsptaglibrary*.xsd and on TLD-related classes. To support validation though we would need to add the XSD-based validation in Jasper. Finally, Jasper parses these documents first into DOM and the into its own version based on TreeNode (this is separate from the parse tree used for actual JSPs). Jasper already depends on tomcat-util for the JarScanner so could potentially use Digester for this in the same way Catalina does. It would simplify the fragment merge logic in JspC if it could reuse what was in Catalina's WebXml (something I'm hacking around in 53737 right now). Alternatively, we could still eliminate the intermediary DOM and TreeNode forms and use SAX or StAX to parse directly into Jasper's objects - especially for TLDs where it is using the spec's classes (TagLibraryInfo and TagInfo) as the model. I'm planning on merging these two patches and pressing on with a converged solution, but probably won't be able to do much until next weekend. Cheers Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements
On Jun 26, 2013, at 12:58 PM, Christopher Schultz
wrote:
> On 6/26/13 2:57 PM, Jeremy Boynes wrote:
>>
>> You wrote in the bug that "annotation's don't make sense" - could you
>> clarify that?
>
> Yes: I was thinking that generating classes that used annotations would
> be a good idea. In retrospect, I don't believe it would be a good idea
> -- at least not by default. Since we are generating a web-fragment,
> there's no need to use annotations. We could also cheat and not use a
> web-fragment and instead use annotations.
>
>> 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.
>
> While that is possible, I see no reason not to explicitly-map the
> servlets individually in a web-fragment. The user can then easily edit
> the single output file (web-fragment.xml) and modify it if necessary.
> For instance, maybe some JSPs shouldn't be called directly.
Perhaps this should be user-configurable (option to generate a web-fragment.xml
or annotations on the generated classes)?
>> BTW, can't we use ServletContext#getEffectiveMajorVersion() to
>> determine the spec-version number?
>
> Sure we can, but JspC doesn't provide a ServletContext...
It kind of does:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/servlet/JspCServletContext.java?view=markup
but it also has its own versions of WebXml and JspConfig, as well as the
JspCompilationContext and JspRuntimeContext. This is one of the areas I found
confusing :)
As I was proposing in my other post, if we could make the compilation process
driven entirely off a ServletContext we can separate the JSP processing from
the context setup which should simplify its implementation. JspC would then
handle setup of a build-time JspCServletContext in the same way Catalina sets
up the runtime ServletContext.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements
On Jun 26, 2013, at 12:10 PM, Nick Williams
wrote:
>
> On Jun 26, 2013, at 1:57 PM, Jeremy Boynes wrote:
>
>> On Jun 26, 2013, at 7:49 AM, Christopher Schultz
>> wrote:
>>
>>> Jeremy,
>>>
>>> On 6/26/13 1:44 AM, Jeremy Boynes wrote:
On Jun 11, 2013, at 1:50 PM, Nick Williams
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 entry with a and
>> 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 , 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 assem
Re: Jasper improvements
Jeremy,
On 6/26/13 2:57 PM, Jeremy Boynes wrote:
> On Jun 26, 2013, at 7:49 AM, Christopher Schultz
> wrote:
>
>> Jeremy,
>>
>> On 6/26/13 1:44 AM, Jeremy Boynes wrote:
>>> On Jun 11, 2013, at 1:50 PM, Nick Williams
>>> 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?
Yes: I was thinking that generating classes that used annotations would
be a good idea. In retrospect, I don't believe it would be a good idea
-- at least not by default. Since we are generating a web-fragment,
there's no need to use annotations. We could also cheat and not use a
web-fragment and instead use annotations.
> 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.
While that is possible, I see no reason not to explicitly-map the
servlets individually in a web-fragment. The user can then easily edit
the single output file (web-fragment.xml) and modify it if necessary.
For instance, maybe some JSPs shouldn't be called directly.
> BTW, can't we use ServletContext#getEffectiveMajorVersion() to
> determine the spec-version number?
Sure we can, but JspC doesn't provide a ServletContext...
-chris
signature.asc
Description: OpenPGP digital signature
Re: Jasper improvements
On Jun 26, 2013, at 1:57 PM, Jeremy Boynes wrote:
> On Jun 26, 2013, at 7:49 AM, Christopher Schultz
> wrote:
>
>> Jeremy,
>>
>> On 6/26/13 1:44 AM, Jeremy Boynes wrote:
>>> On Jun 11, 2013, at 1:50 PM, Nick Williams
>>> 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 entry with a and
> 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 , 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).
N
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements
On Jun 26, 2013, at 7:49 AM, Christopher Schultz
wrote:
> Jeremy,
>
> On 6/26/13 1:44 AM, Jeremy Boynes wrote:
>> On Jun 11, 2013, at 1:50 PM, Nick Williams
>> 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 entry with a and 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.
Cheers
Jeremy
BTW, can't we use ServletContext#getEffectiveMajorVersion() to determine the
spec-version number?
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper improvements, was: Timeline for beginning EL 3.0 implementation?
Jeremy, On 6/26/13 1:44 AM, Jeremy Boynes wrote: > On Jun 11, 2013, at 1:50 PM, Nick Williams > 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. -chris signature.asc Description: OpenPGP digital signature
Jasper improvements, was: Timeline for beginning EL 3.0 implementation?
On Jun 11, 2013, at 1:50 PM, Nick Williams 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). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
