tomcat-users mailing list archives

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

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 ?

Thanks

"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 [mailto:Craig.McClanahan@eng.sun.com]
>Sent: Tuesday, October 10, 2000 7:03 AM
>To: tomcat-dev@jakarta.apache.org; tomcat-user@jakarta.apache.org;
>general@jakarta.apache.org
>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:
>
>
>http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-m2/
>(binary)
>
>
>http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-m2/src
>(source)
>
>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 <http://www.apachecon.com>!
>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 $
>
>
>============
>INTRODUCTION:
>============
>This document describes the changes that have been made in the current
>milestone release of Apache Tomcat, relative to the previous milestone
>release.
>
>Bug reports should be entered at the interim bug reporting system for
>Jakarta projects at:
>
>        http://znutar.cortexity.com:8888/
>
>Please use project codes "Catalina" and "Jasper" for 
>servlet-related and
>
>JSP-related bug reports, respectively.
>
>
>============
>NEW FEATURES:
>============
>
>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
>ServletContext.log()
>method, which will cause them to appear on whatever log the
>administrator
>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 
>org.apache.catalina.util.LocaleToCharsetMap.
>
>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
><Server>
>and <Engine>.  A Service is a grouping of one or more connectors that
>share
>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
>executed.
>
>Catalina:  JMX Management Capability
>------------------------------------
>Catalina now includes a JMX compatible MBean
>(org.apache.catalina.startup.CatalinaManager) that wraps the standard
>startup
>class (org.apache.catalina.startup.Catalina), making Catalina 
>manageable
>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
>fragments
>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
>a
>Container into which web applications (which will be represented by a
>Context
>implementation) can be deployed or undeployed.  StandardHost has been
>extended to support this interface, which means that Catalina can now
>deploy
>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
>path)
>has been added to take advantage of the new hot deploy capabilities of
>Catalina.  This application is useful when you wish to script deploy,
>reload,
>or undeploy operations under control of a client application via HTTP
>commands.
>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
>more
>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
>application
>in which he or she tries to access a protected resource, and 
>the fact of
>this
>authentication is propogated across the other web applications
>associated
>with this virtual host so that the user does not need to log in again.
>
>
>=========
>BUG FIXES:
>=========
>
>Catalina:  Handling of the "Range" header in the default file-serving
>servlet
>is now more robust.
>
>Catalina:  On a request that triggers form-based login processing, save
>the
>query parameters from the original request even if it was a POST.
>
>Jasper:  Fix a parsing bug related to include files with improper tag
>nesting.
>
>Webapps:  Correct build.xml relative references that caused a top-level
>build
>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
>class
>at all, or if you specify a non-existent servlet name or class.
>
>Jasper:  Add conversions for JSP to XJSP run-time attributes to
>XMLOutputter.
>
>Catalina:  Set the "catalina.home" property to the current working
>directory
>if it has not been set in the startup script.
>
>Catalina:  XML parse errors (due to DTD violations) when reading the
>web.xml
>file for either the default ($CATALINA_HOME/conf/web.xml) or 
>application
>
>specific (WEB-INF/web.xml) settings are now reported in the log files,
>and
>cause the application to be unavailable until the errors are fixed and
>the
>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
>found)
>error instead of a 500 (internal server error).
>
>Catalina:  Correctly rethrow exceptions thrown by a servlet that is
>called
>through RequestDispatcher.forward() or RequestDispatcher.include().
>
>Catalina:  Make the default file-serving servlet work correctly when it
>is
>the subject of a RequestDispatcher.include(), even where the calling
>servlet
>has already called response.getWriter() so that binary output cannot be
>used.
>
>Catalina:  If a servlet threw an exception after it had grabbed the
>writer
>with response.getWriter(), the exception report would silently be
>suppressed.
>This has been corrected.
>
>Catalina:  Sending HTTP headers now forces the response to be 
>considered
>
>as committed.
>
>Catalina:  Restore the ability to persist sessions and their attributes
>across
>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
>scheme
>because the org.apache.catalina.session.StandardSession class was not
>visible
>to the web app class loader.  Sessions can now be saved and restored
>without
>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
>under
>JDK 1.3.0, and (b) you did not set the CATALINA_HOME environment
>variable
>to point at your Tomcat 4.0 install directory.
>
>All:  Save all "build.bat" files with DOS line endings.  (All of the
>other
>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
>welcome
>file, it now issues a sendRedirect() to this file, rather than just
>serving
>it directly.  This preserves the semantics of relative links in the
>welcome
>file page, and also causes the welcome files themselves to be protected
>by
>security constraints (if they were not based on the original request
>URI).
>
>
>==============================
>KNOWN PROBLEMS IN THIS RELEASE:
>==============================
>
>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 
>integration
>
>with the other servers currently supported by Tomcat 3.x.
>
>
>URL Decoding Incomplete
>-----------------------
>Currently, Catalina does not decode the values returned by
>getServletPath()
>and getPathInfo(), as required by the Servlet Specification.  This will
>be
>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
>is
>closed".  There appears to be a problem in the JDK's JarURLConnection
>class
>where JAR files are cached, even after they are closed, so that a
>request
>for a connection to the same URL returns the previous JarFile object
>instead
>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 
>environment
>
>  anyway).
>
>
>Clearing Buffer On A Forward
>----------------------------
>The servlet specification requires the container to clear the data
>buffer,
>but not the response headers or cookies, when a servlet calls the
>RequestDispatcher.forward() method.  In the past, this could be done by
>the
>container casting the response back to its internal implementation
>object,
>and calling an implementation-specific method.
>
>This is no longer possible now that the request and response arguments
>to
>a RequestDispatcher.forward() call can be wrapped.  It is likely that a
>new
>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
>forward,
>so you will see any output generated by the calling servlet (or JSP
>page,
>in the case of <jsp:forward>) followed by the output from the
>forwarded-to
>servlet or JSP page.
>

Mime
View raw message