LiteWebServer (LWS) 3.0.3 Release Notes ======================================= This document describes the changes that have been made in the 3.0.3 version of the LiteWebServer (LWS) Base Module. Core ---- * If an XML parser other than the bundled LXP parser (e.g., one bundled with a web application), the DTDs for the web.xml and TLD files were accessed over the Internet. Hence, an application with a web.xml and/or TLDs couldn't be deployed without an Internet connection. This has been fixed by registering an EntityResolver that resolves these references to local resources instead. * Various methods in the com.gefionsoftware.lws.startup.Bootstrap called System.exit() to shutdown the JVM in case of errors. Because this is not what you want when embedding LWS in another application, all public methods in this class now throw a java.lang.IllegalStateException instead. * The module info properties files in the LWS_HOME/etc directory are now optional when running LWS without the JustGetIt module manager. If the properties aren't found, the log messages shows the LWS version as "unknown". * The server.wordir property didn't have any effect. This has been fixed. * Replaced the File.listRoots() based solution for testing if a file path is absolute with the standard File.isAbsolute() method c.g.l.u.ConfigUtils. * The o.a.c.u.ResourceSet class has been moved from the JSP add-on module to the Base module, to fix a problem with ServletContext.getResourcePaths(). * Upgraded all Tomcat classes to Tomcat 4.1.27, fixing the following problems (from the Tomcat release notes; numbers refer to Tomcat bug reports): + CoyoteAdapter: Fix "//" URL normalization code. + JSSESocketFactory: Fix dependency on Sun VMs, so that IBM VM users can use the integrated JSSE. + #21984, HandlerRequest: Fix potential DOS condition when given a malformed URI. Changes in 3.0.2 ================ Core ---- * Fixed parsing of JSP TLDs that takes place at start and restart. Listeners declared in a TLD were not activated in previous versions. * Changed how welcome files are handled. Previously, a redirect to the welcome file was performed, and when the welcome file was represented by a servlet, the file still had to be present to trigger the redirect to the servlet. In this version, the matched welcome file resource (file or servlet) is invoked directly, without doing a redirect. The effect is that the URL in the browser isn't changed to the welcome file URL, which reduces the risk that users bookmark a file URL (e.g. foo/index.html) that is later replaced with another (e.g. foo/index.jsp). It's also slightly faster than a redirect. * Upgraded all Tomcat classes to Tomcat 4.1.24, fixing the following problems (from the Tomcat release notes; numbers refer to Tomcat bug reports): + #15890 DefaultServlet: Invalid date headers should be ignored. + HTTP/1.1 Http11Processor: Fix case sensitivity matching of some special header values, which could prevent HTTP/1.0 keep alive with some clients. + PoolTcpEndpoint: Fix incorrect handling when an exception occurs during a SSL handshake. + PoolTcpEndpoint: More robust socket restart code for the case where an exception occurs during an accept. + ThreadPool: Remove thread from active thread list when it ends. + StandardSession: Don't recycle sessions, as the performance gain is minimal. + CookieTools: Add spaces after ; in cookies. This avoids problems with IE on Mac. + ManagerBase, StandardSession: Correct problems related to the persistence of sessions. + ErrorDispatcherValve Aborted requests by remote clients are now detected so that a one line entry is logged instead of a complete stack trace and the request is terminated instead of trying to invoke an error page. + Cookies: Fix to return values instead of the names. + #17587 Session Manager StoreBase Fix a NPE bug when the background thread expires sessions. JustGetIt Module Manager ------------------------ * Added response headers to prevent caching. * Fixed a case where uninstall could result in a NullPointerException when the file list for the uninstalled module contained non-existent files. Changes in 3.0.1 ================ Installers ---------- The Windows installer has been modified to generate shortcuts directly to the java.exe instead of to custom shortcut (.PIF) files. This fixes the problem with the shortcuts on Windows XP/NT/2000 and avoids the need to increase the environment size on 95/98/ME. A shortcut to the Uninstaller is alse generated by the new installer. The Linux and Unix installers have been modified to use more appropriate file permission settings for all LWS files. Scripts ------- The main scripts (lws.sh and lws.bat) have been modified to make it possible to start LWS without setting any environment variables at all (as long as the defaults are okay, which is true for most cases). JAVA_HOME can still be used to specify a Java installation other than the one in the PATH. This change also makes it possible to start with a JRE instead of an SDK (but note that you must have an SDK for JSP compilarion). See the Reference Manual for details. Core ---- The Bootstrap class has been modified to add the Java SDK tools.jar and JSSE JAR files (if the JSSE_HOME environment variable is set) to the class- path. It also produces a warning message if the Java environment is not an SDK. NOTE! Since the changes in LWS 3.0.1 involve the Bootstrap class and the scripts, you must stop and start LWS after upgrading. For Windows, you must uninstall LWS 3.0 (make sure all files are removed) and use the new installer to get the correct shortcuts generated and the defunct .PIF files removed. Changes in 3.0 ============== General ------- LWS 3.0 is the first version of LWS that is based on the Apache Tomcat 4.1.x source code (specifically the 4.1.18 version) and that is released under a new BSD-style open source license. Using Apache Tomcat as the base allows us to focus on areas such as modularity through add-on modules to let you strike a balance between features, size and complexity; simplified installation, configuration and upgrade processes; documentation and support. Releasing our code as open source is a positive change for all. You can study the code to better understand how it works, modify the code to suit your specific needs, and fix problems yourself instead of waiting for patches from us. We gain from the patches and feature additions you may send us. LWS 3.0 is developed to be very modular, with a base module (this module) that contains the basic HTTP and Servlet support, and add-on modules for extra features like JSP support, authentication support, management tools, etc. The only downside with this change is that the total size of the server is larger than the LWS 2.x version, but it's still not more than roughly 1 MB (smaller if you run on a J2SE 1.4 platform and don't need all features in the base module). The reason for the increase is that the Tomcat core code contains hooks for all the optional features supported by Tomcat. In some cases, these hooks are written so that classes that are not strictly needed in LWS must still be included to avoid runtime errors (NoClassDefFoundException). In other cases, we have choosen to keep code with features LWS currently doesn't expose, to make it easier to expose these features in the future. We hope to work within the Tomcat community to minimize the need to bundle optional classes. As we learn more about what features you need and how to better utilize the Tomcat code, we should be able to bring the size of the base module down a bit more. New features in the base module: * Fully Servlet 2.3 compliant, including support for serving files directly from standard Web Archive (WAR) files * HTTP/1.1 support * HTTPS support with Sun's JSSE package * Auto-deployment of applications, if enabled (default is true) * Auto-reload of changed class files, if enabled (default is false) * Save and restore of serializable session data at server restart * A new API for embedding LWS in another application, with methods for starting, restarting and stopping LWS and programatic configuration. Removed features: * LWS 2.x allowed you to run in Servlet 2.0 backwards compatible mode, making the HttpSession.getSessionContext() method, all methods in the HttpSessionContext interface, and the ServletContext getServlet(), getServletNames() and getServlets() methods return meaningful values instead of the "null values" required by later Servlet specification versions. This option has been removed. * LWS 2.x included a simple web based administration interface. This interface is replaced by the management add-on module. Changes: * The configuration files for LWS-specific features are still simple Java properties files, but the content has been changed. You'll recognize most of the properties in the server.properties file from LWS 2.x, but the configuration previously defined in the servlets.properties, rules.properties and session.properties is now done either in the standard web.xml file for the web application or in the LWS context.properties file. See the Reference Manual for details. Known issues: * When uninstalling modules using the JustGetIt module manager, JAR files are not removed on Windows system due to file locking problems. See Sun's bug ID 4755278 for details. The work-around in this release is to make the JAR files as small as possible by replacing the original content with a dummy entry. To really get rid of the files, you must remove them manually. The etc directory contains a properties file for each module that lists all files that should be deleted. * JNI Based Applications Applications that require native libraries must ensure that the libraries have been loaded prior to use. Typically, this is done with a call like: static { System.loadLibrary("path-to-library-file"); } in some class. However, the application must also ensure that the library is not loaded more than once. If the above code were placed in a class inside the web application (i.e. under /WEB-INF/classes or /WEB-INF/lib), and the application were reloaded, the loadLibrary() call would be attempted a second time. To avoid this problem, place classes that load native libraries outside of the web application, and ensure that the loadLibrary() call is executed only once during the lifetime of a particular JVM. * The JAXP compliant XML parser bundled with LWS (LiteXMLParser) is a minimal implementation of the SAX 2.0 API. It's available to web applications as well, but if you need to use SAX 2.0 extensions or need DOM or XSLT features on a pre-J2SE 1.4 platform, you need to install a parser with those features. * Web application reloading and static fields in shared classes LWS 3.0 allows you to store classes that are used by more than one web application in subdirectories of the "shared" directory (see the Reference Manual). Classes that keep references to objects instantiated by the web application may cause class loading related problems (ClassCastExceptions, messages indicating that the classloader is stopped, etc.), when the auto-reload feature reloads a web application class. To avoid this type of problem, store classes that keeps such references in the "WEB-INF/lib" or "WEB-INF/classes" directories of each web application instead of sharing them. * Linux and Sun JDK 1.2.x - 1.3.x Virtual machine crashes can be experienced when using certain combinations of kernel/glibc under Linux with Sun Hotspot 1.2 to 1.3. The crashes were reported to occur mostly on startup. Sun JDK 1.4 does not exhibit the problems, and neither does IBM JDK for Linux. The problems can be fixed by reducing the default stack size. At bash shell, do "ulimit -s 2048"; use "limit stacksize 2048" for tcsh. GLIBC 2.2 / Linux 2.4 users should also define an environment variable: export LD_ASSUME_KERNEL=2.2.5