On Tue, 10 Apr 2001, Greg Wilkins wrote:
> >...
> > The end result will be a more portable jasper - that will be usable in
> > multiple containers with minimal pain ( and with enough hooks to allow the
> > container to provide specific features and optimizations ).
>
> Excellent - That sounds much easier for us to keep in sync with.
> Still, it would be good to have a maintainer to step forward and help
> us with the transition.... It may be good for somebody on the development
> team to have another servlet container to test against?
Greg, I was hoping for the reverse - have jetty developers help with
jasper refactoring.
I will download the code and take a look anyway - the part I'm interested
in is allowing jasper to take advantage of servlet container
features ( and avoid double mapping and buffering, do better reloading,
etc), and looking at other containers can only help.
This is a very interesting ( and not easy ) project - we are still in the
planning stage, and getting people with experience in other containers
will help us a lot ( and I'm sure the end result will be much better ).
> The first change we made was to provide a logging facade class, so that the
> link with tomcat logging could be broken. Jasper code makes logging calls
> on a Jasper class, which we have implemented to call the Jetty logging
> facility. This probably should be generalized so that a dynamically
> selected logging facade can be configured for JSP.
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 ).
What I was thinking is slightly different - i.e. use a Event/Listener
model for notifications ( that would completely decouple jasper from the
logger, and would allow some nice tricks ).
> Secondly we replaced the XML parsing with our own wrappers for a JAXP
> parser. As Jetty is targetted for small memory footprint systems, we
> wish to avoid DOM as it is too heavy weight when you consider it is often
> only used only to read a config file (once loaded, the DOM classes stay
> in memory). I think a generic jasper should probably only assume a JAXP
> parser in the environment and then only use the SAX elements of it.
+1
Replacing DOM with SAX would be great, and making it a separate component
would be even better ( the container may provide the information without
requiring a second parsing ).
For small footprint I was thinking ( for tc3.3 ) to generate a serialized
version of web.xml, that would allow an embedded tomcat to work without
requiring a parser ( assuming pre-compiled jsps ).
Do you have this working ? Can you contribute it (back) to jasper ?
> Another concern I have is that I don't think that jasper should be parsing
> the web.xml file itself. Consider an deployment in an EJB container that
> uses JSP, the web.xml may be parsed 3 times, once by the EJB container looking
> for ejb-ref tags, once by the servlet container and then finally by the
> JspServlet. I think Jasper should be written to allow a deployer to push
> this configuration into it. Initially it would have to have it's own pusher that
> did parse the web.xml file, but eventually it would be good to make a proposal
> to the servlet spec guys to come up with an API to allow a servlet container
> to export the parts of the web.xml it does not know how to handle.
+1 - again, this is part of the "jasper cooperating with the
container" problem.
I think there are at least 5 intended goals for this refactoring:
1. better JspServlet ( Mel is working on that ). The result shouldn't make
any assumptions on the container.
2. jasper "cooperation" with the servlet container - for example jasper
may register a generated servlet and avoid container->JspServlet->Servlet
indirection, integrate with container services, etc
3. More flexible code generation - by modularizing the generator you
should be able to plug a different generator. That would allow experiments
like using XSLT for generation, generate better code, etc.
4. general refactoring to improve code readability, extensibility,
maintainability ( required for all the above )
5. merge the x versions of jasper while maintaining all the features. By
spliting jasper in components you should be able to pick the pieces you
need:
- JspInterceptor + JDK1.1 compatible runtime + JSP1.1 generator + Mangler
+ URLClassLoader + IntegratedXmlReader == tomcat 3.3 jasper
- JspServlet + JDK1.2 runtime + JSP1.2 generator + ... = tomcat
4.0-compatible jasper
- Jetty-specific adapter + WhateverJDKYouRequire + JSP1.x generator +
... == jetty jasper
- JspServlet + .... = portable jasper ( independent of any container ).
> The classloading configuration is a bit ugly. I'm not sure how this
> can be cleaned up, but currently in Jetty we have hard coded detection of the
> JspServlet so that the context classloader can be set as an InitParam. It
> would be better jasper could do a better job of trying to locate the context
> classloader itself.
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.
> Is there a jasper specific mailing list that we can tune into to monitor
> your jasper efforts? or is it just the general tomcat dev mailing list?
> If nobody steps forward to help maintain jetty-jasper (I call it jesper :-)
> and transition to the new portable version, then it would be good to have
> a focused mailing list to monitor and contribute to.
tomcat-dev is the list we use ( for jasper, tomcat 3.3, tomcat4.0, flames,
etc :-).
Costin
