On 08/07/2013 06:38, Jeremy Boynes wrote: > On Jun 25, 2013, at 10:44 PM, 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.
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
