Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jettyproject.
On Wed, 11 Apr 2001, Greg Wilkins wrote: [EMAIL PROTECTED] wrote: That's reasonably easy to do ( in 3.3 workspace the Log is just an independent class ,with no dependency on tomcat internals - except that it's in tomcat.util.log package ). The only hestiation I have with that, is packaging. It is likely that the tomcat.util.log class will be normally packaged in a tomcat.jar. If you start copying classes from jar to jar, then you can end up with duplicates and if people start sealing jars, everything breaks down. I know. Most utils should move to a "jakarta-commons-sandbox" package, i.e. outside of tomcat tree ( but that'll be after tc3.3 is released ). Not easy - unless URLClassLoader is used ( or per thread class loader ? ). This is a big issue for JspServlet, also the work dir and reloading, but are not big issues if "cooperating" jasper+containers. Except that URLClassLoader is probably more trouble than it is worth. It makes reloading difficult (I guess JSP checks the source anyway?) and the fact that most JVMs have a broken JarURLConnection that does not see modified jars makes this even worse! Take a look at org.apache.tomcat.util.depend.* ( again, no dependency on tomcat, except the name of the package ). If reloading is enabled we just wrap URLClassLoader in a DependClassLoader that delegates everything and records all the loaded .class files into a DependManager. Then .class dependecies are treated the same as any other dependecies ( web.xml, .jar files, etc ). As Mel said that he does not want to dive into the guts of jasper just yet, changing the jsp loaders is probably a bit much to ask for now. Actually, loaders are the most important piece to fix, as it creates the most problems and is the hardest to integrate. Manglers are the next. ( of course, the first step is to separate all things in packages and find a good mechanism to plug them and check everything still works ) Costin
Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jettyproject.
On Tue, 10 Apr 2001, Mel Martinez wrote: Greg, I am writing the jasper34 refactoring proposal. I am late on getting it checked in because I have been distracted by other issues (job hunting, for one). I am nearly ready to submit it though. It is currently in the form of a UML class model generated with Together. I will submit it in html form inside the tomcat 3.3 proposals directory for review. Mel, could you bring me up to date on a couple of issues regarding this proposed proposal :-)? * Are you planning on supporting the new JSP 1.2 features? If not, this isn't going to be of much use for Tomcat 4.0. * Are you planning on maintaining compatibility with JDK 1.1? I don't personally like the idea of Tomcat 4.0's JSP environment being constrained by this -- either in the internal code of Jasper itself, or in the generated code for the servlet associated with each page. Craig
Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jettyproject.
On Tue, 10 Apr 2001, Mel Martinez wrote: The design philosophy used is to create a 'toolkit' of factory and accessor methods for creating and accessing services required by Jasper adapter implementations such as JspServlet, JspC and JspInterceptor. The "toolkit" idea is perfect for what we need, and preferably with as little coupling/dependencies as possible between components. For a "cooperating" container only the Jsp parser and generator ( and the runtime ) are relevant, all other packages are services to be used in JspServlet or to change the behavior. Having a "jaser.core" that acts as a repository for jasper modules ( or JasperToolkit if it's only a class) is a good idea too. One important thing is to make sure the "runtime" services are clearly separated from the "compile" services. ( you may want to create a small-footprint container that includes only the runtime and uses pre-compiled applications ). Costin
