Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
[EMAIL PROTECTED] wrote: On Tue, 10 Apr 2001, Greg Wilkins wrote: 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. We don't have anybody on jetty that has really got into the internals of jasper, so we are not in the best position to be actual contributors. However as this refactoring is exactly what we are looking for, the Jetty developers may well be your number one alpha testers! 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. Remember our branch is an orphan child. So our changes may indicate requirements, but may not represent the best approach :-) 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 ). I think we will try to use the refactored jasper both as a servlet and potenitally as a Jetty HttpHandler (our own extension component), so we should give it a good shake down. 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. So to my way of thinking, using one class - even an interface - from another jar, may as well be a dependancy on every class in that jar. I would prefer if the jasper toolkit described it's own logging interface as part of the toolkit - the default implementation could be the tomcat log. Furthermore, I think that the jasper log service API may need to be richer than a standard log API. One of the most common complaints we get with JSP is that it either show too much or not enough details when something goes wrong. It may be that the logging API should distinguish between exceptions and errors coming from the generation process from those from the running of the JSPs.Normally this would not be a problem, but I think that jasper sometimes hides the real exception from the servlet container (which should log it as any other servlet exception). A custom jasper logging API should allow different classes of logs to be identified and customized for JSPs. How these are mapped to the underlying log mechanism is installation specific. 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 ). That would also do the trick. We're listening 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 ? For now we have tied the jesper XML parsing to our own XmlParser wrapper for JAXP parsers. It has it's own mini dom light document structure and it allows extra ContentHandlers to register interest in particular tags, so they are called back while the main parsing is within the scope of that tag. This is all very Jetty specific and really is the mechanism that we would use within our own implementation of the jasper xml toolkit component that provides web.xml content. 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. 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
Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
Costin, [EMAIL PROTECTED] 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? It is not an easy project - and it would be great to get help, feedback and sugestions from jetty developers. Ok - I'll give brief over view of the changes and ideas that we have at the moment. 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. 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. 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. For example - the jetty/jboss integration module under development now registers for callbacks when the container parses ejb-ref tags. 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. Finally I also have a few half formed ideas of how to improve the generation of web.xml fragments by the pre-compiler, so that it pays better attention to existing jsp mappings in the existing web.xml. 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. And just to end on a positive note... our users that have switched from our older versions to our jasper based version have reported positive feedback with regards to performance and stability. regards On Mon, 9 Apr 2001, Greg Wilkins wrote: The Jetty project is in need of a Jasper maintainer for it's cut of the Jasper JSP engine. Jetty is a opensource java HTTP server and servlet container (see http://jetty.mortbay.com or http://sourceforge.net/projects/jetty) It is intended to be small, fast, yet fully functional. For JSP handling, we have taken a branch of the jasper code. The branch was required as we need to decouple the logging and XML parsing from tomcat. However, this branch is now a little bit of an orphan and requires a maintainer to : + Keep it up to date with the latest jasper development. + Cleanup the current jetty integration - specially with regards to classloading, logging and XML parsing. + Feedback changes and suggestions that may make jasper more portable between servlet containers (this may require removal of Jetty dependancies that were added in place of tomcat ones). + Testing of the integration using watchdog. + Planning and executing the upgrade of Jetty from servlet 2.2 and JSP1.1 to 2.3/1.2. Anybody who can help with some or all of this will be warmly welcomed to the Jetty project. I'm not subscribed to tomcat-dev, so can responses be directed to [EMAIL PROTECTED] or [EMAIL PROTECTED] regards Yahoo! Groups Sponsor -~-~ Secure your servers with 128-bit SSL encryption! Grab your copy of VeriSign's FREE Guide, "Securing Your Web site for Business." Get it now! http://us.click.yahoo.com/KVNB7A/e.WCAA/bT0EAA/CxaWlB/TM
Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
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.
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 base toolkit class, JasperToolkit has one main
static method : createToolkit(..) that allows an
implementation to retrieve an instance of the desired
toolkit subclass. It then uses the instance methods
of the retrieved toolkit to access the desired
services. The base JasperToolkit class is being
written to support a common pattern by which all of
the common service implementations can easily be
specified via configuration properties. A subclass,
specific to a particular implementation of Jasper can
override any or all of the factories to allow
specification of the service implementations using
runtime information such as init-params or whatever.
Importantly subclasses can also extend the toolkit to
provide methods for services that are particular to
that jasper implementation. And finally, subclasses
can apply optimization and life-cycle management of
service objects as appropriate for the particular
implementation.
While it took me that big, long paragraph to explain
it, it is actually quite simple to use and extend.
This is just an abstract factory, after all.
The 'common' services, that might potentially need to
be overridden by a particular adapter, that I've
identified to include in the base JasperToolkit so far
are:
toolkit -- the toolkit subclass used
jspfactory -- the JspFactory implementation
pagehandler -- handles the page life cycle
requesthandler - handles the request life cycle
jspcompiler -- compiles the .jsp to .java
javacompiler -- compiles the .java to .class
jspmangler -- calculates class, package file
names
modificationchecker -- checks whether to recompile
cache -- provides object caching for performance
Thus, all of the above can be easily re-implemented
and replaced, providing easy customization of Jasper.
To use this toolkit facade, a jasper adapter needs to
be rewritten to access these services through the
toolkit. This is done quite simply like so:
JspServletToolkit tk = (JspServletToolkit)
JasperToolkit.createToolkit("JspServlet");
//
JspMangler mangler =
tk.getJspMangler(jspUri,outputDir);
String javafile = mangler.getJavaFileName();
// ...etc...
I will be supplying a new version of JspServlet to use
this as a first cut. One extention that the
JspServlet will provide is a factory for generating
appropriate class loaders (something not needed by all
implementations) and to use init-params to specify
service implemenations during run-time. This will all
be done 'separately but in parallel' to the current
JspServlet implementation so as to not break anything.
The model specifically stays away from modifications
to Jasper's parser/compiler behavior because this
effort is about refactoring the adapters first.
It sounds like you would like to include the XML
parser in the list of 'replaceable' parts. I had not
thought to try to address that (yet) because that gets
into the internals of the jasper compiler itself (none
of the above does). This model will easily support
the idea of adding a factory for that service and then
rewriting the jasper compiler to retrieve the XML
parser via the toolkit, so I don't see any problem
with adding that. However, it requires a bit of
diligence to derive the appropriate interface or
facade for that service and I don't want to put any
time into that just yet. Once I get the proposal
submitted, and folks have had a chance to understand
the pattern, I would welcome any suggestions on
additional services to add, whether to the base
toolkit or whether they belong only in subclass
toolkits.
Regarding the issue of whether Jasper should re-parse
the web.xml file: This gets to the heart of why we
need this refactoring. In the case of running Jasper
inside Tomcat, we can easily factor in the fact that
the servlet engine has already read the web.xml file
and implement an adapter to leverage that info in our
use of Jasper. That is done with JspInterceptor.
However, for those of us using Jasper as a stand-alone
jsp compiler inside other servlet engines (via
JspServlet), the problem is that the Servlet API
provides no way to carry that information across to
JspServlet in a standard way, reliable when using
other servlet engines. Further, it is not clear that
the JspC implementation of Jasper even NEEDS web.xml
information. Thus, it is clear that another useful
service to abstract through the toolkit is
RE: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
-Original Message- From: Mel Martinez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 10, 2001 2:56 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project. other servlet engines. Further, it is not clear that the JspC implementation of Jasper even NEEDS web.xml information. Thus, it is clear that another useful Taglib map in web.xml is why JspC needs web.xml. Otherwise the compiler can't find the java classes that implement the tag. Now, you don't need that for JSP-Java, but remember that step is an implementation detail. It's actually JSP-class. I'd like to be able to use JspC as part of a web application packaging tool, and for that, it should be able to generate classes, not just java source. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
--- [EMAIL PROTECTED] wrote: The "toolkit" idea is perfect for what we need, and preferably with as little coupling/dependencies as possible between components. That's the goal! 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. The way I want it to work is for the base JasperToolkit to only provide services common or potentially used by all adapter implementations. Then, an adapter implementation can use a specific subclass that provides any additional services specific to that implementation. Since this would be an adapter-savvy toolkit, it can use runtime smarts apropriate for that adapter. Now, it is possible that the core toolkit will include factory methods for services not used by a particular implementation. That's okay. The penalty for class-loading is only the interface classes used as return types by the factory methods since the implementation classes are only loaded when the factory methods actually get invoked. That keeps the toolkit pretty lightweight even if it has a few extra unneeded factories. That said, as soon as I get this posted, I'll be wide open to suggestions on better partitioning of services or adding ones I've missed. Maybe multiple base toolkits will be appropriate instead of one. For example, the one I'm designing is concerned with supporting the runtime adapter implementations. It might make sense to have a separate factory for generating the many classes used by the JSP parser itself. If so, maybe my current 'JasperToolkit' should instead be named 'AdapterToolkit', reserving the former name for the parser/compiler toolkit? This will be a good discussion to have. Well, I'm going to get back to work on it. Cheers, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
I tried to respond to this earlier today, but aparently my mail message got zapped into the netherworld. --- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: On Tue, 10 Apr 2001, Mel Martinez wrote: 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. The toolkit refactoring strategy is agnostic as to JSP 1.2 or 1.1 features. That is the point. This model should make it EASIER to replace existing features and behavior with new implementations. Thus, while not aimed specifically at providing JSP 1.2 features, this should help get there. * 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. One of the benefits of the Abstract Factory pattern is to remove dependencies on particular language version or platform dependencies. The toolkit itself must be written to be compatible with jdk1.1, as required for tomcat 3.x. However, any given *implementation* of a service provided by the toolkit can ignore jdk1.1 and use nothing but the latest and greatest Java language features. Such an implementation could even be used on tomcat 3.3 - but in that case, the factory method that instantiates that service needs to be prepared to supply an alternative in the jdk1.1 case. Since it is likely a tc4 version of this will use a specific subclass of the toolkit to add new services, it can just ignore this issue. For overriding existing services with new implementations, that is done simply by setting a config property so again, tc4 would not have to concern itself with backward compatibility at all. The whole thing is analogous to the way AWT and JFC factories work, except this is much smaller and simpler. :-) I hope this is helpful. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: Jasper JSP maintainer required for Jetty project.
Hi Greg, We are planning a small refactoring of jasper ( at least for tomcat3.3, but one goal would be to merge the 2 branches we have in jakarta ). I don't know when this will happen, but I know few people are looking into that. Mel already made a proposal for improving JspServlet, and I will probably make another one ( for the code generator and parser, plus extra modularization ) as soon as I finish reviewing/fixing the 3.3 bugs. 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 ). It is not an easy project - and it would be great to get help, feedback and sugestions from jetty developers. Costin On Mon, 9 Apr 2001, Greg Wilkins wrote: The Jetty project is in need of a Jasper maintainer for it's cut of the Jasper JSP engine. Jetty is a opensource java HTTP server and servlet container (see http://jetty.mortbay.com or http://sourceforge.net/projects/jetty) It is intended to be small, fast, yet fully functional. For JSP handling, we have taken a branch of the jasper code. The branch was required as we need to decouple the logging and XML parsing from tomcat. However, this branch is now a little bit of an orphan and requires a maintainer to : + Keep it up to date with the latest jasper development. + Cleanup the current jetty integration - specially with regards to classloading, logging and XML parsing. + Feedback changes and suggestions that may make jasper more portable between servlet containers (this may require removal of Jetty dependancies that were added in place of tomcat ones). + Testing of the integration using watchdog. + Planning and executing the upgrade of Jetty from servlet 2.2 and JSP1.1 to 2.3/1.2. Anybody who can help with some or all of this will be warmly welcomed to the Jetty project. I'm not subscribed to tomcat-dev, so can responses be directed to [EMAIL PROTECTED] or [EMAIL PROTECTED] regards
Re: Jasper JSP maintainer required for Jetty project.
on 4/9/01 2:13 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: We are planning a small refactoring of jasper ( at least for tomcat3.3, but one goal would be to merge the 2 branches we have in jakarta ). I don't know when this will happen, but I know few people are looking into that. Where is that plan in this document? http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat/RELEASE-PLAN-3.3? rev=1.8content-type=text/vnd.viewcvs-markup Also, someone should update the dates in the document to reflect reality. -jon
Re: Jasper JSP maintainer required for Jetty project.
On Mon, 9 Apr 2001, Jon Stevens wrote: on 4/9/01 2:13 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: We are planning a small refactoring of jasper ( at least for tomcat3.3, but one goal would be to merge the 2 branches we have in jakarta ). I don't know when this will happen, but I know few people are looking into that. Where is that plan in this document? http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat/RELEASE-PLAN-3.3? rev=1.8content-type=text/vnd.viewcvs-markup Jasper refactoring will happen in a "revolution"-space ( i.e. will be proposals/jasperXX - with 43 or 73 as proposed names ), so it has nothing to do with the RELEASE-PLAN. When ready, it'll work as an add-on module to 3.3 ( and I hope 4.0 and other containers ), and may be integrated in a 3.3.1 ( if needed ) As far as I know 3.3 is close to freeze, except the encoding bugs that still don't have a solution and will require a new milestone ( assuming we find a fix :-), changing the jasper code that will go into the release is very unlikely. Costin
Re: Jasper JSP maintainer required for Jetty project.
on 4/9/01 2:54 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: On Mon, 9 Apr 2001, Jon Stevens wrote: on 4/9/01 2:13 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: We are planning a small refactoring of jasper ( at least for tomcat3.3, but one goal would be to merge the 2 branches we have in jakarta ). I don't know when this will happen, but I know few people are looking into that. Where is that plan in this document? http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat/RELEASE-PLAN-3.3? rev=1.8content-type=text/vnd.viewcvs-markup Jasper refactoring will happen in a "revolution"-space ( i.e. will be proposals/jasperXX - with 43 or 73 as proposed names ), so it has nothing to do with the RELEASE-PLAN. When ready, it'll work as an add-on module to 3.3 ( and I hope 4.0 and other containers ), and may be integrated in a 3.3.1 ( if needed ) As far as I know 3.3 is close to freeze, except the encoding bugs that still don't have a solution and will require a new milestone ( assuming we find a fix :-), changing the jasper code that will go into the release is very unlikely. Costin Ok, I read your email as if it was going into Tomcat 3.3... -jon
RE: Jasper JSP maintainer required for Jetty project.
-Original Message- From: Jon Stevens To: tomcat-dev Sent: 4/9/01 6:30 PM Subject: Re: Jasper JSP maintainer required for Jetty project. on 4/9/01 2:13 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: We are planning a small refactoring of jasper ( at least for tomcat3.3, but one goal would be to merge the 2 branches we have in jakarta ). I don't know when this will happen, but I know few people are looking into that. Where is that plan in this document? http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat/RELEASE-PLAN- 3.3? rev=1.8content-type=text/vnd.viewcvs-markup Also, someone should update the dates in the document to reflect reality. Regrettably I have been swamped with other work lately. I'll try to get it updated in the near future. Larry
