tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <>
Subject RE: [ANNOUNCEMENT] Tomcat 4.0 Milestone 2 Released
Date Tue, 10 Oct 2000 08:49:01 GMT

I'm preparing the RPM but I've got a problem with two JAVA packages:

README.TXT say we need jndi & jmx. 

Can they be distributed with the src RPM ?


"Dans les révolutions, il y a deux sortes de gens: ceux qui les font et ceux
qui en profitent "
-- Napoleon 

>-----Original Message-----
>From: Craig R. McClanahan []
>Sent: Tuesday, October 10, 2000 7:03 AM
>Subject: [ANNOUNCEMENT] Tomcat 4.0 Milestone 2 Released
>I am happy to announce that a milestone 2 release of Tomcat 4.0 is now
>available for download at:
>Compared to Milestone 1, this version has significant new features and
>bug fixes, as summarized in the Release Notes that are included below
>for your convenience.
>Please help us improve the quality of the Tomcat 4.0 release by
>downloading and testing this release, and reporting any bugs you find
>(or other improvement suggestions) in the bug tracking system described
>in the Release Notes).
>Craig McClanahan
>See you at ApacheCon Europe <>!
>Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
>Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
>                                    Applications to Tomcat
>                Apache Tomcat Version 4.0 Milestone 2
>                =====================================
>                            Release Notes
>                            =============
>$Id: RELEASE-NOTES-4.0-M2.txt,v 1.9 2000/10/10 03:52:46 craigmcc Exp $
>This document describes the changes that have been made in the current
>milestone release of Apache Tomcat, relative to the previous milestone
>Bug reports should be entered at the interim bug reporting system for
>Jakarta projects at:
>Please use project codes "Catalina" and "Jasper" for 
>servlet-related and
>JSP-related bug reports, respectively.
>Catalina: New Class Loader Structure
>To implement the Servlet Spec 2.3 requirements related to declaring a
>dependency on external optional packages, a new class loader for the
>shared contents of $CATALINA_HOME/lib is now created, and made visible
>to all web applications.  See Section 9.6.1 of the Servlet 2.3 spec.
>Jasper:  Support for PropertyEditors
>Jasper now supports the new JSP 1.2 requirement that if a bean 
>class has
>declared a PropertyEditor for one or more bean properties, 
>those editors
>will be used to perform String-to-object conversions.
>Jasper:  Logs to ServletContext.log()
>Log messages created by Jasper now default to using the
>method, which will cause them to appear on whatever log the
>has configured for this web application.
>Catalina:  Locale To Character Set Mapping
>Previously, the mapping from locales to character sets was done by a
>hard coded mapping table in 
>This has been made more flexible in the following respects:
>* The mapping table used by default is now initialized from an external
>  property resource file that can be edited and replaced.
>* The character set mapping implementation component is now pluggable
>  on a per-web-application basis.
>Catalina:  New Configuration Component in SERVER.XML
>A new configurable component, <Service> has been introduced between
>and <Engine>.  A Service is a grouping of one or more connectors that
>a particular Container (normally an Engine) to process incoming
>requests.  A
>single Server instance can contain any number of Services.
>Catalina:  Developer Document Added
>A new developer document ("catalina/docs/dev/classloaders.html") has
>been added
>describing the new class loader hierarchy created when Catalina is
>Catalina:  JMX Management Capability
>Catalina now includes a JMX compatible MBean
>(org.apache.catalina.startup.CatalinaManager) that wraps the standard
>class (org.apache.catalina.startup.Catalina), making Catalina 
>in a
>JMX agent.  You can also use JMX to manage an integrated 
>instance of the
>org.apache.catalina.startup.Embedded class.
>Jasper:  Expanded Acceptance of XML Syntax
>In conformance with the direction of the expert group for the JSP 1.2
>specification, Jasper know accepts well-formed (in the XML sense) XML
>anywhere that #PCDATA can appear in an XML-syntax JSP page, without
>having to
>wrap these fragments inside CDATA sections.
>Catalina:  New Deployer Interface
>A new top-level interface called Deployer has been created.  It defines
>Container into which web applications (which will be represented by a
>implementation) can be deployed or undeployed.  StandardHost has been
>extended to support this interface, which means that Catalina can now
>and undeploy applications on the fly, without having to be restarted.
>Catalina:  New Manager Web Application
>A new web application (by default attached to the "/manager" context
>has been added to take advantage of the new hot deploy capabilities of
>Catalina.  This application is useful when you wish to script deploy,
>or undeploy operations under control of a client application via HTTP
>As such, it is complementary to administrative applications with a more
>human-oriented user interface that have yet to be created.  See a new
>document in the source distribution (catalina/docs/manager.html) for a
>complete description of this new application.
>Catalina:  Single Sign On Support
>Catalina now supports the ability to configure "single sign on" across
>all of
>the web applications for a particular virtual host.  This facility
>supports a
>user experience where the user is authenticated by the first web
>in which he or she tries to access a protected resource, and 
>the fact of
>authentication is propogated across the other web applications
>with this virtual host so that the user does not need to log in again.
>Catalina:  Handling of the "Range" header in the default file-serving
>is now more robust.
>Catalina:  On a request that triggers form-based login processing, save
>query parameters from the original request even if it was a POST.
>Jasper:  Fix a parsing bug related to include files with improper tag
>Webapps:  Correct build.xml relative references that caused a top-level
>from a fresh checkout of the jakarta-tomcat-4.0 module to fail.
>Catalina:  Finish implementing the new Servlet 2.3 functionality on the
>WrappedRequest class.
>Catalina:  Modify the information string returned by
>ServletContext.getServerInfo() to include a slash in the usual format.
>Catalina:  Clean up error handling behavior in the invoker 
>servlet.  Now
>returns 404 errors (instead of 500) if you specify no servlet name or
>at all, or if you specify a non-existent servlet name or class.
>Jasper:  Add conversions for JSP to XJSP run-time attributes to
>Catalina:  Set the "catalina.home" property to the current working
>if it has not been set in the startup script.
>Catalina:  XML parse errors (due to DTD violations) when reading the
>file for either the default ($CATALINA_HOME/conf/web.xml) or 
>specific (WEB-INF/web.xml) settings are now reported in the log files,
>cause the application to be unavailable until the errors are fixed and
>application restarted.
>Jasper:  Correctly populate the "urn" field of TagLibraryInfo from the
><uri> element in the tag library descriptor.
>Jasper:  Requesting a non-existent JSP page now returns a 404 (not
>error instead of a 500 (internal server error).
>Catalina:  Correctly rethrow exceptions thrown by a servlet that is
>through RequestDispatcher.forward() or RequestDispatcher.include().
>Catalina:  Make the default file-serving servlet work correctly when it
>the subject of a RequestDispatcher.include(), even where the calling
>has already called response.getWriter() so that binary output cannot be
>Catalina:  If a servlet threw an exception after it had grabbed the
>with response.getWriter(), the exception report would silently be
>This has been corrected.
>Catalina:  Sending HTTP headers now forces the response to be 
>as committed.
>Catalina:  Restore the ability to persist sessions and their attributes
>a context reload or a server restart, the same way that Tomcat 3.x can
>do it.
>This ability was disrupted when Catalina changed to a multi-classloader
>because the org.apache.catalina.session.StandardSession class was not
>to the web app class loader.  Sessions can now be saved and restored
>requiring this capability.
>Catalina: Fixed a classloader bug that would cause the WEB-INF/classes
>directory to be ignored on Windows platforms if (a) you were running
>JDK 1.3.0, and (b) you did not set the CATALINA_HOME environment
>to point at your Tomcat 4.0 install directory.
>All:  Save all "build.bat" files with DOS line endings.  (All of the
>scripts have the correct line endings set when they are copied to their
>destination directories.)
>Catalina:  When the default file-serving servlet decides to serve a
>file, it now issues a sendRedirect() to this file, rather than just
>it directly.  This preserves the semantics of relative links in the
>file page, and also causes the welcome files themselves to be protected
>security constraints (if they were not based on the original request
>No Web Connectors Available
>Current releases of Tomcat 4.0 only run in stand-alone mode.  A new web
>connector for Apache will be integrated shortly, followed by 
>with the other servers currently supported by Tomcat 3.x.
>URL Decoding Incomplete
>Currently, Catalina does not decode the values returned by
>and getPathInfo(), as required by the Servlet Specification.  This will
>dealt with after clarifications to the requirements are 
>completed in the
>JSR-053 expert group.
>Redeploying From a Web Application Archive
>If you attempt to undeploy, then redeploy, an application from the same
>web application archive file URL (where the URL refers to an actual WAR
>file, not to a directory), the redeploy will fail with error "zip file
>closed".  There appears to be a problem in the JDK's JarURLConnection
>where JAR files are cached, even after they are closed, so that a
>for a connection to the same URL returns the previous JarFile object
>of a new one.  As a workaround, you should do one of the following:
>* Change the URL of the web application archive each time you redeploy.
>* Deploy from an unpacked directory (on the same server) 
>instead of from
>  a WAR file (this is often more convenient in a development 
>  anyway).
>Clearing Buffer On A Forward
>The servlet specification requires the container to clear the data
>but not the response headers or cookies, when a servlet calls the
>RequestDispatcher.forward() method.  In the past, this could be done by
>container casting the response back to its internal implementation
>and calling an implementation-specific method.
>This is no longer possible now that the request and response arguments
>a RequestDispatcher.forward() call can be wrapped.  It is likely that a
>public method will be added to the ServletResponse API for this
>purpose.  In
>the mean time, Tomcat 4.0 does *not* clear the response buffer on a
>so you will see any output generated by the calling servlet (or JSP
>in the case of <jsp:forward>) followed by the output from the
>servlet or JSP page.

View raw message