This is the Beta version of the Java Server FAQ. It has the following sections:
In later releases, you should expect that many of the answers now found here will be addressed in the main Java Server documentation.
See Known Bugs for a list of known bugs and their workarounds. Please review this list before reporting a bug.
Server:
Servlets:
Reference:
There's no "package" to install at this time. We are using
a two distribution formats, tar files, which works on all the
platforms we support, and Win32 .exe
files for
Windows platforms. Packages only work on Solaris and other
UNIXes derived from System V release 4 sources. Just "untar" the
distribution and follow the installation instructions.
Make sure of the following:
You need to modify the classpath used by your compiler so that it includes the Java Server lib/classes.zip file. With JavaSoft's JDK, you can do this either by modifying the CLASSPATH environment variable or by passing a suitable -classpath flag to the javac compiler invocation. Some other Java compilers have different requirements.
Java Server requires JDK1.1 or later to run. Your CLASSPATH environment variable is pointing to earlier version of the JDK. If you're using JavaSoft's JDK, download the latest version of the JDK and add it to your CLASSPATH (instructions are included with the JDK). Otherwise, if you're not using JavaSoft's JDK, then get the upgrade which your product vendor should have made available by now.
For the Solaris platform we currently provide an /etc/rc script, the server_root/etc/java-server.startup file; read this for installation instructions. Support for other platforms will be provided in one of our future releases.
No. When running the Java Web Server in a Unix environment it is better to unset the CLASSPATH variable. The CLASSPATH variable is handled by the http daemon, httpd.
Make sure httpd is running as root. If you still see this problem when running as root, it might be a bug with the operating system. Solaris 2.5 has a bug which will not allow this to work. Upgrading to 2.5.1 or later will fix this problem.
A high level description of JMAPI is: "A Java Management API that provides a rich set of extensible Java objects and methods for building applets that can be used to manage an enterprise network over Internets."
We are not writing a tool to manage an enterprise network. We are writing one that is a component that can be managed in such a framework. So our roadmap includes plans to fit our tool into existing system and network management tools as required by our customers. Tools using JMAPI, SNMP, and CMIP are all possible candidates for such integration.
In addition we plan to integrate with existing operating system facilities as much as possible. For instance, while we provide our own user, group, and ACL management, our first release includes support for existing Unix users. Standard tools can be then used to administer security policies and we will work with those.
This is the log file which servlets and server can use for messages of arbitrary format. Arbitrary format is also used by the Error Log. The Access Log uses the common log file format.
Properties are what Java applications (i.e HotJava) use for default administration. They are simply a series of name-value pairs. We do not anticipate administrators needing to manually modify most of the administration files, since we are currently working on web based administration tools.
When upgrading the JavaServer, the configuration files may be overwritten. To avoid this, the current workaround is to copy your current configuration files to a safe location during a Java Server upgrade. Copy the old/safe configuration files over the new ones once the upgrade is complete. This problem will be remedied in the future by a more robust installation procedure.
Servlets are objects which conform to a specific interface that can be plugged into a Java-based server. Servlets are similar to applets in that they are object bytecodes that can be dynamically loaded off the net, but differ from applets in that they are faceless objects (without any graphics). They serve as platform independent dynamically loadable pluggable helper bytecode objects on the server side. Servlets are a first step towards agents, but they differ from agents in that they need to be explicitly invoked on and moved.
Like applets, servlets are identified by a URL address:
http://server_host/MyServlet.class
Servlets can be loaded in two ways. One is by loading the html file that is mapped to a servlet name on the server side. The AdminApplet file maps the html name into a servlet name and the servlet name into a servlet class. The servlet class must be found in the CLASSPATH environment of the server. The second way to load a servlet is to specify the name of the servlet in the URL. For this the "/servlet/" identifier can be used, and the servlet invoker automatically loads the named servlet. For more information, see Servlet Loading and Invoking.
A servlet invoker is a servlet that invokes the "service" method on a named servlet. If the servlet is not loaded in the server, then the invoker first loads the servlet (either from local disk or from the network) and the then invokes the "service" method. Also like applets, local servlets in the server can be identified by just the class name. In other words, if a servlet name is not absolute, it is treated as local.
Servlets can be invoked by a client in the following ways:
The server gets a request for a document, looks up the configuration parameters, finds out that the document is not a static document residing on the disk, but a live document generated by a servlet object, and forwards the request to the servlet which services the request by generating the output. This method is the same as used by traditional web servers for invoking CGI scripts.
The client invokes the servlet with a URL of the form:
http://server_host/servlet/<servlet URL>
where the <servlet URL> is a regular URL that points to the location of the servlet. The host where servlet resides might be different from the host where the server is running. In this case the servlet class will be dynamically downloaded to the server, instantiated and then run. The reason this invocation is useful is that it does not need any special understanding of servlets on the part of the browser.
Any file ending with .shtml is a server parsed file. In .shtml, if a servlet tag or server-insert tag is present, then the server will run the servlet and insert the output generated by the servlet in the place of the insert tag.
In Beta, servlets can be dropped in to the servlets/ directory relative to the root of the server. Servlets placed in this directory can be invoked using their class names as follows (assuming HelloWorld.class was placed in the server_root/servlets directory):
http://server_host_name:8080/servlet/HelloWorld
A class_file.initArgs file can be placed in the same directory for passing init
args to the servlet in question. For example to pass two init args A=B and C=D
to the HelloWorld servlet. A HelloWorld.initArgs file must be created in the
extensions dir whose syntax would be:
A=B
C=B
When Servlets are recompiled in this directory - the new version will be automatically
loaded by the server.
Arguments to the servlets can be passed at two levels.
<servlet code="servlet_name" stock_symbol="SUNW">
Once activated, servlets live on until the server lives or until the destroy method is called on the servlet by the server. The servlets with association in servlet aliases, unmapping the alias will destroy the servlet, and subsequent access to the servlet will reload the servlet.
See the Core Servlets page, and the Servlet Examples page for information on some of the available servlets. Also look in the server_root/servlets directory of the release for more servlets.
Make sure that your CLASSPATH is set to include the Java Server classes. This can be done at the command line (using java -classpath ....) or else in the environment variable.
The following is the proper syntax:
SSIncludeServlet will clone its ServletRequest, and substitute the parameters embedded in the tag.
There are a number of sources for more information on the Java Programming Language. General information is available at the JavaSoft Web Site, including a Java tutorial, a free binary release of the Java Developers Kit, and extensive documentation. There are also a number of books available on Java - see your local technical bookstore for a selection.
NCSA's Common
Gateway Interface page is a good resource for CGI information. It
includes information on how to use CGI with form output.
Top
java-server-feedback@java.sun.com