NOTE: This document is a draft of a release plan for the next dot release of Tomcat. Nothing in this document should be considered authoritative until it has been discussed and approved on the TOMCAT-DEV mailing list. Tomcat 3.3 Release Plan ======================= Objective: The objective of the proposed 3.3 release is to complete the development of jakarta-tomcat 3.x and achieve the stated goals of providing a production quality 2.2/1.1 servlet container. Changes: Tomcat 3.3 will implement no new major features compared with 3.2. Some tuning and improvements are made to various modules to increase the usability and flexibility. The STATUS.HTML document summarizes some of these changes in the action items marked for the 3.3 release. The "changes3.3" document provides a more detailed list of the code changes. Most of the changes are related with continuing the refactoring of the 3.x and performance enhancements that couldn't make it into 3.2. Tomcat 3.3 Milestone 1 Release: Code Freeze/Tag Date: Feb 8, 2001 Release Manager: Larry Isaacs To help insure widespread testing, this build must include an acceptably simple way of running the internal Tomcat tests and Watchdog in some form. The build must pass all watchdog and all existing test suites. It should work on both JDK1.1 and JDK1.2. After the build of Milestone 1, work should start in reviewing all the classes and interfaces in tomcat.core, and any feedback should be discussed and incorporated. Also, the documentation will be reviewed and improved. In parallel, work will start on fixing all bugs and making other changes as required by the Release criteria given below. This work will continue during the beta period. Whenever possible, we should try to create a self-test case ( using the current self-test application and GTest ). It is desirable to add more documentation on running GTest and the test application, to simplify the testing work. We must test and make sure that JspServlet still function properly. Tomcat 3.3 Milestone 2 Release: Code Freeze/Tag Date: March 1, 2001 Release Manager: Larry Isaacs This release is optional depending on the amount of bug fixing that occurs since the milestone 1 release. The major goal of the week following milestone 1 will be to identify what further work is needed based on the feedback. During this time it is hoped that there will be enough bug fixes and tests added to make this release worthwhile. Should that not be the case, this release may be skipped since the beta release is expected a week later. Tomcat 3.3 Milestone 3 Release: Code Freeze/Tag Date: May 12, 2001 Release Manager: Larry Isaacs Known issues in order of priority 1. Verify that JSP source is not served when escaping tricks are used 2. Update build process to create archives and internal directory structure consistent with other Jakarta projects, i.e. use jakarta-tomcat-3.3-xxx. Tomcat 3.3 Milestone 4 Release: Code Freeze/Tag Date: June 20, 2001 Release Manager: Larry Isaacs This release contains a switch to using jakarta-tomcat-connectors for some utility classes. It also uses jakarta-tomcat-jasper for building jasper34, which will be enabled as the default JSP handler. The internal "jasper33" will be enabled as the default JSP handler for future releases of Tomcat 3.3. Known issues in order of priority: 1. Jasper34 needs to be stable. 2. Watchdog and internal test need to be passing all tests. 3. Build documentation need to be updated to document new dependencies on jakarta-tomcat-connectors and jakarta-tomcat-jasper. Tomcat 3.3 Beta 1: Code Freeze/Tag Date: July 11, 2001 Release Manager: Larry Isaacs No major change will be done after the Beta is build without a vote. The release team can reject any change they feel is too big and can introduce regressions, or is not needed. No major bug ( spec compliance or stability ) should be open in order to enter beta. During the beta period we will fix all remaining bugs and run the manual tests for the bugs that have no automated test case. Known issues in order of priority: 1. Port all missing updates to Jasper from Tomcat 3.2.2 and verify that all Jasper theading issues are dealt with. This includes Bugzilla Bugs 80,140,1039,1123,1280,1646 2. Check HttpSessionFacade for spec compliance. Know problems: A. setAttribute() calls valueBound() after storing the object in the session. The spec calls for the reverse. B. setAttribute() doesn't call valueUnbound() for the object it replaces, if present. 3. Fix getResource() to not allow access to files outside of the web application. 4. Session recyling includes keeping the HttpSessionFacade. I believe this represents a security risk. May need to discard session facades, or at least discard them for untrusted web applications. 5. getRequestURI() should return an encoded string 6. Update getRemoteHost() to be consistent with Tomcat 3.2.2, which does a reverse DNS lookup. 7. Verify no reqressions. 8. TBD... Tomcat 3.3 Beta 2: Code Freeze/Tag Date: July 18, 2001 Release Manager: Larry Isaacs This release should fix any major bugs found in the prior beta and any missed regressions. Known issues in order of priority: 1. TBD... Tomcat 3.3 Release Candidate 1: Code Freeze/Tag Date: Sept 14, 2001 Release Manager: Larry Isaacs This release should be used to verify that we really are at release quality. It should include any fixes needed to reach that status. Documentation updates may continue after this release. To Be Addressed for RC1: 1. HttpSessionFacade.setAttribute() isn't synchronized. If a second request called "setAttribute()" after this request's "removeAttribute()" and before "realSession.setAttribute()", the second request's value would be overwritten without an valueUnbound() being called. RESOLUTION: Implemented 2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This is referred to in Bug #177. See: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for details. I think ServletHandler.init() is currently subject to this vulnerability. RESOLUTION: Implemented 3. The spec doesn't address whether a the form-login-page and form-error-page should be excluded from the security-constraint, but it makes sense that it should. It might be best to postpone this. RESOLUTION: Postponed. 4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for isTomcatAuthentication() to see if req.setRemoteUser() should be called. I think Ajp13 doesn't have this yet and probably should. Also, if the user is anonymous, i.e. user = "", should we call req.setRemoteUser() with this value? This prevents Tomcat's normal authentication from being triggered. RESOLUTION: tomcatAuthentication property has been added to Ajp13. 5. If a error handler is not found for an exception, check the root cause as well if it is a ServletException. This is mentioned in Bug 3233. I think it would be a good idea to apply this. I don't think we are prohibited by the spec. We could add an option to be safe if there is concern. RESOLUTION: Implemented. 6. StaticInterceptor is missing a localization enhancement added to Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Is this still considered a regression, though it isn't part of the Servlet 2.2/JSP 1.1 spec? RESOLUTION: Postponed to RC2 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. RESOLUTION: Minimized vulnerability. Must Resolve Bugs: 1253 Frequent Connection reset by peer errors RESOLUTION: Later Tomcat 3.3 Release Candidate 2: Code Freeze/Tag Date: Oct 6, 2001 Release Manager: Larry Isaacs Will be the build put to a vote as a release. This release should only include very minor fixes and documentation updates from the RC1 release. To Be Addressed by RC2: 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. RESOLUTION: Implemented 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. RESOLUTION: Current file set is okay. Check again before building RC2. 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr to files. With the default server.xml with no path for tc_log, Tomcat's startup output ends up in the "stderr" log. I would have expected it to be in the "stdout" log. Is there a reason the o.a.t.u.qlog.Logger uses stderr as the default sink instead of stdout? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the "why don't you" questions. IN PROGRESS: Current implementation under review 12. To simplify upgrade development, I would like to see the classpath for the "container", "common", and "apps" classloaders include the directory so classes placed under them will be picked up. RESOLUTION: Implemented. Includes "dir/classes" directory if exists. 13. Determine cause of pauses running Tomcat's internal test with Tomcat + IIS. RESOLUTION: Removed "bad" request test. IIS hangs on POST using HTTP/0.9 14. StaticInterceptor is missing a localization enhancement added to Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Must Resolve Bugs: 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after 2333 HTTP Reason will be destroyed in header using AJP12 3760/3727 When forwaring from one servlet to another, path info may get lost Tomcat 3.3 Final Release Code Freeze Date: Oct 15, 2001 Release Manager: Larry Isaacs The final build. The pre-requisite for the release is having no bugs in the test suite, resolution for all known bugs and approval by the community. Open in 3.2.x But Fixed in 3.3 384 AJP13 returns no Status Message (Reason-Phrase RFC 2616) Bug Bugs That Won't Be Fixed In Tomcat 3.3 The following Bugzilla Bugs are known issues that are not planned to be addressed in Tomcat 3.3. Bug #75: Translation time attribute evaluation not provided to TagExtraInfo class Bug #143: Tag handlers with properties of type "Object" Bug #155: Quick Blurb saying "Everything is initialized" Bug #164: IIS Logging Bug #203: `tomcat.sh env` ruins the shell if $TOMCAT_HOME is not set Bug #451: ServletException displaying wrong lines in debug information Bug #481: Misleading exception report Bug #524: Can't use Apache SSI with mod_jserv Bug #631: RequestDispatcher.include output is in wrong order Bug #1057: Context Paths and numerals. Bug #1433: Comments are parsed inside tag. Release criteria ================ The standards of quality and testing will be significantly higher than in previous releases. 1. Tomcat 3.3 should have no regression compared with 3.2. Any reported regression is a show-stopper and a release can't be made before it is resolved. 2. Open bugs should be fixed, if possible. 3. Tomcat 3.3 should be tested with existing, complex applications ( cocoon, bugrat, etc ). 4. Jasper must include bug fixes that were done in both 3.2.x and 4.0, and various enhancements that are deemed appropriate. 5. All bugs that have been opened after the Tomcat 3.2.1 release will be resolved before a 3.3 release is made. "Resolved" means that one of the "resolutions" supported by BugZilla has been assigned to the bug. 6. Full review of the code, making sure the modularity and extensibility goals have been achieved. 7. Make sure that the refactoring is clean, and maintenance will be easier that 3.2 8. Ensure that the performance is (significantly) better than 3.2 9. Ensure that Jasper is compatible (as much as possible) with the version used in the proposed 4.0. This refers to behavior differences outside of the JSP spec, which could create problems moving a web application from Tomcat 3.3 to Tomcat 4.x. Platforms. We must make sure that tomcat test reports ( at least watchdog + self-test ) contributed by developers and users exists for at least Linux, Solaris, Windows 9x, Windows NT/2000. It is desirable to have test reports on MacOS 9/X, FreeBSD. JDK. We must test tomcat with at least JDK1.1 and Java2 (multiple versions if possible) . The tests should also include a stress test ( a high load "ab" running for a long time ) Configurations Tomcat must be tested standalone, with Apache 1.3, Apache 2.0 and ( possibly ) with IIS and NES ( low priority ). Maintenance Plan ================= The release team must consist of at least 3 people, and will fix any major bugs that will be found after the 3.3 release, and propose to the group minor releases, if absolutely needed ( security or stability bugs ). In any case, no backward-incompatible or major changes should be made. The release team must coordinate the maintenance and support of tomcat, dispatching bugs and user requests to developers and acting as the last resort in resolving major support issues. Release Team ============ The release team will be composed of the committers that give the binding +1 on the release plan and release proposal. It must have at least 3 members, and follow the rules that will be established. The release team will coordinate the execution of the release plan, dispatch bugs to volunteers, review commits, and act as a lead in the release process. One of the team members will act as "Release Manager" and will be responsible for building the milestones, making the announcements about the release progress and all other roles that will be set by PMC and committers.