Contents / New Features / Administrator Docs / Developer Docs / Index
This section of the document contains JWS 1.1.1 updates to the following sections:
The Java Web Server runs on any platform that supports the Java Development Kit 1.1 or above.
(They were previously kept under each service, for example:
<server_root>/properties/service_defaults/proxy/session.properties
The template servlet has been split into two parts. One part, still called the TemplateServlet is the traditional servlet that is named "template" in the system. The new part is the TemplateFilter and is named "templatefilter". If you need to filter content from JHTML or SSI into the Presentation Template engine, use the templatefilter. This fixes a bug present in the TemplateServlet that shipped with 1.1.
NOTE: On the UNIX realm, it is not possible to add a user through the Java Web Server. The UNIX realm is controlled through the DNS database and users must be added through that mechanism.Of course, the reference to DNS (Domain Name Service) is incorrect, it should have said NIS (Network Information Service).
To create a keys.passphrase file:
To use the stored password when manually starting the Java Web Server on either Solaris or Windows platforms:
% httpd -passfile
% httpd -passfile
To use the stored password when you are set up for automatic server start-up on the Windows NT platform:
Start -> Settings -> Control Panel -> Services -> Startup Parameters
-passfile
.You will need to use the passphrase file if all 3 of the following conditions are true:
If this is the case, when the Java Web Server boots and it goes to bring up the Secure Web Service, it needs a password. However, an NT service has no way to communicate with the desktop so it isn't able to tell the desktop to put up a dialogue box asking for the passphrase.
That's why, in the above case, you would have to have a passfile in the proper place (as described above) with the passphrase in it. The Java Web Server will automatically look for the file and use it if it is there.
The security mechanism for page-compile servlets is simple:
Note: This reflects a change in the security model of page-compile servlets between the Beta and final (FCS) versions of Java Web Server 1.1.
This section contains a listing of the more important bugs fixed in the Java Web Server 1.1.1 release. Entries in parentheses indicate the same entry appears earlier in the list.
Note: Java Developer Connection membership is free but does require registration for access. Details on how to become a Java Developer Connection member are provided on JavaSoft's For Developers web page.
Bug Id | Description | |
---|---|---|
Servlets | ||
4117402 | CGI-programs invoked by CgiServlet cannot work with TCP/IP | |
4102382 | Directory listings created by FileServlet are invalid HTML | |
4103370 | Servlets are being init()'d more than once | |
4109986 | PageCompileServlet handles <FORM> tag incorrectly | |
CGI | ||
(4117402 | CGI-programs invoked by CgiServlet cannot work with TCP/IP) | |
4098278 | Changes to the cgi script directory are not dynamic | |
4098182 | win32: Server needs to be restarted for cgi to work | |
Startup/Shutdown | ||
4107883 | -Dsystem_property=value argument not working in jserv script | |
4106944 | win32: Double quotes inside the PATH environment variable does not allow httpd start | |
4099422 | win32: Can't start httpd or authstore if installing on directory with spaces | |
4107869 | Can't shut down the server when session tracking is turned off. | |
Session Tracking | ||
(4107869 | Can't shut down the server when session tracking is turned off.) | |
4109927 | Sessions aren't shared across services in same server | |
Security | ||
4109874 | ErrorServlet generates <base href> tag, causing failure of secure sessions. | |
4100694 | HEAD /protected.html returns a 401 Unauthorized even if you send authorization code | |
DO, PUT, GET, DELETE | ||
4093380 | win32: Does not use the archive directory when HTTP PUT overwrites file. | |
4097982 | DELETE/PUT are allowed when Security Check is disabled on admintool. | |
4098129 | win32: PUT does not flush last few files that are PUT | |
Page Compilation | ||
4109986 | PageCompileServlet handles <FORM> tag incorrectly | |
4087488 | HEAD returns content length of 0 for shtml and jhtml files | |
Miscellaneous | ||
(4087488 | HEAD returns content length of 0 for shtml and jhtml files) | |
4102375 | Spaces of a File Name in Directory Listing are Not Escaped | |
4098844 | addservice utility throws NullPointerException when server has keys file | |
4102524 | MIME type for *.Z doesn't work | |
4114495 | Bogus errors appearing in errorlog - IllegalAccessException | |
4103115 | Servlet chaining doesn't pass headers. | |
4116549 | Java Web Server 1.1 does not log NullPointerExceptions to error_log |
sendRedirect and sendError each create a complete response object by performing the following calls: setStatus, setHeader (in the case of sendRedirect), setContentLength, and then a series of println's. For this reason, neither sendRedirect nor sendError should be used where you are need to manage a part of the response explicitly. (For instance, you would not call either of these methods just after you set the status or just before you print to the output stream.)
If you use the sendRedirect or sendError methods incorrectly (for instance, in conjunction with println),you will get a "write past end of stream" error message.
The Java Web Server ships with a Java Runtime Environment (JRE). By default, the Java Web Server uses this included JRE -- which means you don't have to be concerned about your CLASSPATH or JAVAHOME settings, their values are ignored unless you explicitly say otherwise when you start the server.
If you want the Java Web Server to find and access additional classes (for example, ones you've written), you can do this in any of the following ways:
If you are using the default JRE and its associated class path, all jar files in this lib subdirectory of <server_root> are automatically added to the classpath.
If you are using the default JRE and its associated class path, this classes subdirectory of <server_root> is automatically added to your classpath.
Note: With this method, classes cannot be in jar format.
C:\JavaWebServer1.1\bin\httpd -classpath C:\JDK1.1.4\classes (Windows example) % httpd -classpath /usr/local/classes (Solaris example)
In all of the above cases, <server_root> refers to the directory containing the installed Java Web Server product.
This document has the following sections:
Page compilation allows JavaTM and HTML to be integrated on the same page. The Java code controls the output on the page, because the page is compiled into a servlet before the output is sent to the client.
Sessions give the stateless HTTP protocol the ability to maintain state between requests to the server. The state is maintained via server-side cookies and/or URL rewriting.
Templates allow the look and feel of a web site to be customized, without having to change every web page within that site. The template "wraps around" HTML documents to present a consistent user experience.
JavaTM Web ServerTM 1.1 implements the HTTP 1.1 protocol. As such, the Java Web Server now supports content negotiation, chunked encoding, byte range operations, caching, and persistent connections. In addition, the methods PUT, DELETE, OPTIONS, and TRACE are also implemented. Note that PUT and DELETE are restricted to protected resources only.
These basic upload servlets handle uploads as performed by NetscapeTM browsers versions 3 and 4.
Note: it is not an implementation of RFC 1867; it is merely a subset of it.
New security features include support for NT realms as well as support for more Certificate Authorities than the five precompiled ones in the 1.0 version of Java Web Server.
Now you can use servlets that are also beans. The servlet bean adheres to the JavaBeansTM design patterns, allowing you to get or set properties and to save state in serialized files.
The Trial Version of the Java Webserver contains all the features of the full version of the API. However, the number of simultaneous connections allowed to it has been limited to 5. This means that if more than one browser at a time connects to it, the response will be either be extremly slow, or connections may be rejected. As a side effect of this limitation, you will not be able to adjust the maximum or minimum number of threads in the admin tool.
To obtain the full version of the JavaWebServer, please to go
The Javasoft Web Site, and purchase a copy.
Changes to the Servlet API
The following are the latest additions to the Java Servlet API. These additions are upwardly compatible for servlet developers. They will, however, affect developers who write servers that load and use their own servlets, and developers who write servlet-embedding engines.
HttpServletRequest class
HttpServletResponse class
HttpServlet class
HttpServletRequest class
HttpServletResponse class
HttpSession class
HttpSessionBindingListener class
HttpSessionContext class
The Java Web Server runs on any platform that supports the Java Development Kit 1.1 or above.
The compressed file is approximately 14 MB.
To install it, you require roughly 20 MB of hard drive space.
The compressed file is approximately 10 MB.
To install it, you require roughly 13 MB of hard drive space.
For the server environment, you need EITHER:
Note: The Windows and Solaris distributions of this product take care of this for you; they are bundled with the JRE 1.1.4.
For up-to-date information on whether your target platform supports JDK 1.1, please contact the platform's vendor.
In addition, on Windows 95, you need:
WinSock2 may be downloaded from Microsoft's site at:
http://www.microsoft.com/win32dev/netwrk/winsock2/ws295sdk.html
Note: You cannot run the Java Web Server on Windows 95 in disconnected mode. This is because Windows 95 will not recognize local host with WinSock2 installed. (This problem does not affect Windows NT 4.0, which ships with WinSock2.)
For the the client environment, you need:
Note: Most browsers are JDK 1.0.2-compatible. Netscape Navigator (3.0, 4.0), Microsoft Internet Explorer (3.0), and AppletViewer (1.0.2, 1.1) are known to be compatible.
This section contains workarounds for some of the bugs known at the time of the Java Web Server 1.1 release.
For the most up-to-date list of bugs and their workarounds, JavaSM Developer ConnectionSM members should see the Bug Parade page on the Java Developer Connection web site. Please look at these before you report a new bug.
Note: Java Developer Connection membership is free but does require registration for access. Details on how to become a Java Developer Connection member are provided on JavaSoft's For Developers web page.
where server_root is the name you chose for the directory into which you installed the product. By default, the install program names that directory JavaWebServer1.1
To remove it automatically:
or, to remove it manually:
To avoid this confusion, do not create usernames with spaces.
Or if you have already done so, type underscore characters in
the places where the spaces would be.
Permissions on Logs
When first installed, no log directory is created.
It is created by the server runtime the first time the server is started.
Permissions on the logs are granted based on the user running the server
at this initial time.
For example, if you run the server for the first time as a usernameA, the logs are owned by usernameA. Subsequent runs by any other user (including root) will result in a "failure to open logs" error due to permission problems.
To correct this problem, either run the server for the first time as "nobody" or reset the permissions on the logs.
JAVA_HOME=C:"\PROGRAM FILES\JAVA"
The affected variables are PATH, JAVA_HOME, and CLASSPATH.
Microsoft Internet Explorer and HTTPS
Some versions of Microsoft Internet Explorer, including 3.0 and 3.01,
have been observed to crash when using the Secure HTTP protocol (HTTPS)
to talk to the Java Web Server. This is a bug which Microsoft appears
to have fixed in more recent versions of Internet Explorer, such as
IE4.0b1. If you have problems using HTTPS, either use another browser,
such as Netscape Navigator 3.0 (or later), or get the bug-fixed
version of Internet Explorer from Microsoft.
To work around this problem, either
chmod -R og-w JavaWebServer1.1
% tar xvfp tarfile
For details on doing how to perform these steps, see the
Properties document.
If You Have Lost Your Password
If, by chance, you change your Administration password and then forget it
and can no longer get access to the Java Web Server Administration Tool, you can
recover by following these steps:
server_root/realms/data/adminRealm/keyfile
admin
line there so that it reads:
admin::YWRtaW4=
admin
, error
,
file
, invoker
, linkcheck
,
loganalyzer
, snoop
, cgi
, and
ssinclude
servlets.
If, by chance, you do find yourself locked out of the Java Web Server because
of the assignment of access controls to any of the core internal
servlets, you can recover from this situation quite easily by editing
the acl.properties
file for the service in which you
assigned the access controls.
To edit the acl.properties file:
server_root/properties/server/javawebserver/service_name
acl.properties
in your favorite text editor.
For example, if you have set
access controls on the admin
servlet in the realm
defaultRealm
using the Access Control defaultACL
the line would look like this:
Servlet.admin=Basic:defaultRealm:defaultAcl
You should now be able to log in normally to the Java Web Server.
If you change your document root and move protected files to it, you must restart the server.
To restart the server:
For example, events are logged through the Tracelog class by default. Thus the entry for logging events in the systemdefaults.properties file is:
log.event.formatclass=com.sun.server.log.Tracelog
If you customize your logging with custom classes, you need to change the value of log.name.formatclass to point to the name of the custom class that will handle the requests for the various types of logging. For example:
log.event.formatclass=com.sun.server.log.MyEventLogFormatter
You will also need to subclass the appropriate classes and override the appropriate methods.
Note that the req and res objects are the same objects used in the servlet API. You can call req.getHeader(String string), for instance.
In both cases, (extending tracelog and httplog)
all writing to the system logs should be done with the print() methods of
sun.server.log.Log. Also, access to the system logs output stream
can be obtained by using the getOutputStream method of
Log.
Java Web Server and The JDBC-ODBC Bridge
We recommend that people do not attempt to use the JDBC-ODBC bridge
with the Java Web Server 1.1 product. We instead recommend that
users use only Pure Java JDBC drivers. Drivers that use native code
are subject to platform vagaries that can crash the Java Web Server
entirely.
There are many reasons for this. The two most compelling are:
To use the stored password when manually starting the Java Web Server on either Solaris or Windows platforms, type:
% httpd -passfile
% httpd -passfile
To use the stored password when you are set up for automatic server start-up on the Windows NT platform:
Start -> Settings -> Control Panel -> Services -> Startup Parameters
-passfile
.
![]() |
Copyright © 1997
Sun Microsystems, Inc. All Rights Reserved. |