Rimfaxe Web Server

Bootstrapping APIs for JAXP parsers. This is the first portable API defined for bootstrapping DOM.

JAXP parsers bootstrap in two stages. First is getting a factory, and configuring it. Second is asking that factory for a parser.

The SAX bootstrapping support corresponds to functionality found in the org.xml.sax.helpers package, except that it uses the JAXP two stage bootstrap paradigm and that the parser that's bootstrapped is normally wrapping a SAX parser rather than exposing it for direct use.

Base "TRAX" API for XSLT transformers. This API borrows many structural notions from SAX, such as the way error handling and external entity resolution are handled, although it does not reuse the corresponding SAX classes. To use XSLT transformers:

• Start with TransformerFactory.newInstance();
• Then you may wish to configure that factory through its features and properties. This includes modifying the way errors are handled and URIs are resolved.
• Then you have several options for how to perform the XSLT transformations. One generic option is to ask the factory for a Transformer and then use Transformer.transform() to pull input text onto output text.
• Alternatively, most factories support flexible integration with SAX event streams. You can cast such factories to a SAXTransformerFactory and perform either push or pull mode transformations.

The OutputKeys class holds constants that can be used to configure output properties used with Result objects, as if they were specified in xslt:output attributes in the stylesheet specifying the transform.

The Templates class accomodates the notion of "compiled" transforms.

Support for DOM inputs and outputs to transformers.

Support for SAX2-based XSLT transformers. Normally you would cast a TransformerFactory to a SAXTransformerFactory and use that to in any of the various modes supported (such as push or pull).

Support for text stream inputs and outputs to transformers.

This package contains a set of Task implementations for Ant (version 1.4 or later) that can be used to interact with the Manager application to install, reload, and remove web applications from a running instance of Tomcat. For more information, see http://jakarta.apache.org/tomcat/tomcat-4.0-doc/manager-howto.html.

The attributes of each task element correspond exactly to the request parameters that are included with an HTTP request sent directly to the Manager application. They are summarized as follows:

NOTE - Commands executed through the Manager application are NOT reflected in updates to the Tomcat server.xml configuration file, so they do not persist past the next time you restart the entire Tomcat container.

This package contains Authenticator implementations for the various supported authentication methods (BASIC, DIGEST, and FORM). In addition, there is a convenience base class, AuthenticatorBase, for customized Authenticator implementations.

If you are using the standard context configuration class (org.apache.catalina.startup.ContextConfig) to configure the Authenticator associated with a particular context, you can register the Java class to be used for each possible authentication method by modifying the following Properties file:

    src/share/org/apache/catalina/startup/Authenticators.properties

Each of the standard implementations extends a common base class (AuthenticatorBase), which is configured by setting the following JavaBeans properties (with default values in square brackets):

• cache - Should we cache authenticated Principals (thus avoiding per-request lookups in our underyling Realm) if this request is part of an HTTP session? [true]
• debug - Debugging detail level for this component. [0]

The standard authentication methods that are currently provided include:

• BasicAuthenticator - Implements HTTP BASIC authentication, as described in RFC 2617.
• DigestAuthenticator - Implements HTTP DIGEST authentication, as described in RFC 2617.
• FormAuthenticator - Implements FORM-BASED authentication, as described in the Servlet API Specification, version 2.2.

This package contains code for Clustering, the base class of a Cluster is org.apache.catalina.Cluster implementations of this class is done when implementing a new Cluster protocol

The only Cluster protocol currently implemented is a MulticastProtocol
    StandardCluster.java

In addition to the Cluster implementation StandardCluster there's a listener and a sender implemented using multicasting.

• MulticastSender - A ClusterSender implementation that works with a MulticastSocket
• MulticastReceiver - A ClusterReceiver implementation that works with a MulticastSocket

Both extend the common class ClusterSessionBase which provides common functionality shared by the two implementations.

This package contains Java objects that represent complex data structures from the web application deployment descriptor file (web.xml). It is assumed that these objects will be initialized within the context of a single thread, and then referenced in a read-only manner subsequent to that time. Therefore, no multi-thread synchronization is utilized within the implementation classes.

This package contains Realm implementations for the various supported realm technologies for authenticating users and identifying their associated roles. The Realm that is associated with a web application's Context (or a hierarchically superior Container) is used to resolve authentication and role presence questions when a web application uses container managed security as described in the Servlet API Specification, version 2.2.

The implementations share a common base class that supports basic functionality for all of the standard Realm implementations, and can be configured by setting the following properties (default values are in square brackets):

• debug - Debugging detail level for this component. [0]

The standard Realm implementations that are currently available include the following (with additional configuration properties as specified):

• JDBCRealm - Implementation of Realm that operates from data stored in a relational database that is accessed via a JDBC driver. The name of the driver, database connection information, and the names of the relevant tables and columns are configured with the following additional properties:
  • connectionURL - The URL to use when connecting to this database. [REQUIRED - NO DEFAULT]
  • driverName - Fully qualified Java class name of the JDBC driver to be used. [REQUIRED - NO DEFAULT]
  • roleNameCol - Name of the database column that contains role names. [REQUIRED - NO DEFAULT]
  • userCredCol - Name of the database column that contains the user's credentials (i.e. password) in cleartext. [REQUIRED - NO DEFAULT]
  • userNameCol - Name of the database column that contains the user's logon username. [REQUIRED - NO DEFAULT]
  • userRoleTable - Name of the database table containing user role information. This table must include the columns specified by the userNameCol and roleNameCol properties. [REQUIRED - NO DEFAULT]
  • userTable - Name of the database table containing user information. This table must include the columns specified by the userNameCol and userCredCol properties. [REQUIRED - NO DEFAULT]
• MemoryRealm - Implementation of Realm that uses the contents of a simple XML file (conf/tomcat-users.xml) as the list of valid users and their roles. This implementation is primarily to demonstrate that the authentication technology functions correctly, and is not anticipated as adequate for general purpose use. This component supports the following additional properties:
  • pathname - Pathname of the XML file containing our user and role information. If a relative pathname is specified, it is resolved against the pathname specified by the "catalina.home" system property. [conf/tomcat-users.xml]

This package contains Servlets that implement some of the standard functionality provided by the Catalina servlet container. Because these servlets are in the org.apache.catalina package hierarchy, they are in the privileged position of being able to reference internal server data structures, which application level servlets are prevented from accessing (by the application class loader implementation).

To the extent that these servlets depend upon internal Catalina data structures, they are obviously not portable to other servlet container environments. However, they can be used as models for creating application level servlets that provide similar capabilities -- most obviously the DefaultServlet implementation, which serves static resources when Catalina runs stand-alone.

This package contains the standard Manager and Session implementations that represent the collection of active sessions and the individual sessions themselves, respectively, that are associated with a Context. Additional implementations of the Manager interface can be based upon the supplied convenience base class (ManagerBase), if desired. Different implementations of Session are possible, but a need for functionality beyond what is provided by the standard implementation (StandardSession) is not expected.

The convenience ManagerBase base class is configured by setting the following properties:

• algorithm - Message digest algorithm to be used when generating session identifiers. This must be the name of an algorithm supported by the java.security.MessageDigest class on your platform. [DEFAULT_ALGORITHM]
• debug - Debugging detail level for this component. [0]
• distributable - Has the web application we are associated with been marked as "distributable"? If it has, attempts to add or replace a session attribute object that does not implement the java.io.Serializable interface will be rejected. [false]
• entropy - A string initialization parameter that is used to increase the entropy of the seeding of the random number generator used in creation of session identifiers. [NONE]
• maxInactiveInterval - The default maximum inactive interval, in minutes, for sessions created by this Manager. The standard implementation automatically updates this value based on the configuration settings in the web application deployment descriptor. [60]
• randomClass - The Java class name of the random number generator to be used when creating session identifiers for this Manager. [java.security.SecureRandom]

The standard implementation of the Manager interface (StandardManager) supports the following additional configuration properties:

• checkInterval - The interval, in seconds, between checks for sessions that have expired and should be invalidated. [60]
• maxActiveSessions - The maximum number of active sessions that will be allowed, or -1 for no limit. [-1]
• pathname - Pathname to the file that is used to store session data persistently across container restarts. If this pathname is relative, it is resolved against the temporary working directory provided by our associated Context, if any. ["sessions.ser"]

This package contains code that is used by the SsiInvoker.

This class consists of SsiMediator.java which works as a mediator between the different SsiCommands. To add a command you have to implement the SsiCommand interface and extend the SsiMediator. Commands currently implemented are

• SsiConfig - Implementation of the NCSA command Config i.e. <!--#config errmsg="error?"-->
• SsiEcho - Implementation of the NCSA command Echo i.e. <!--#echo var="SERVER_NAME"-->
• SsiExec - Not implemented
• SsiFlastMod - Implementation of the NCSA command flastmod i.e. <!--#flastmod virtual="file"-->
• SsiFsize - Implementation of the NCSA command fsize i.e. <!--#fsize file="file"-->
• SsiInclude - Implementation of the NCSA command Include i.e. <!--#config virtual="includefile"-->

This package contains a variety of small Valve implementations that do not warrant being packaged separately. In addition, there is a convenience base class (ValveBase) that supports the usual mechanisms for including custom Valves into the corresponding Pipeline.

Other packages that include Valves include org.apache.tomcat.logger and org.apache.tomcat.security.

This package contains a memory based naming service provider.

This package contains object factories used by the naming service.

This package contains the URL context factory for the "java" namespace.

This package contains the resources directory context implemetation. This includes :

• A CacheDirContext which handles caching and acts as a proxy for the real resources context
• A FileDirContext, an implementation of DirContext to access the filesystem

Contains the core and "XML" feature set of the DOM Level 2 Recommendation.

Supports the optional "CSS" and "CSS2" stylesheet features of the DOM Level 2 Recommendation.

Supports the optional "Events", "UIEvents", "MouseEvents", "MutationEvents", and "HTMLEvents" features of the DOM Level 2 Recommendation.

Note that apart from the basic "Events" infrastructure and the "MutationEvents", all other events currently defined in the DOM specification imply having some user interface that issues various events to the DOM. Also, to fully support the "UIEvents" and its child event set "MouseEvents", the DOM implementation must also support the "Views" feature.

Supports the optional "HTML" feature of the second DOM Level 2 Candidate Recommendation.

Supports the optional "Range" feature of the DOM Level 2 Recommendation.

Supports optional "StyleSheets" features (see the sibling CSS package) of the DOM Level 2 Recommendation.

Supports the optional "Traversal" feature of the DOM Level 2 Recommendation.

Supports the optional "Views" feature of the DOM Level 2 Recommendation.

This package provides the core SAX APIs. Some SAX1 APIs are deprecated to encourage integration of namespace-awareness into designs of new applications and into maintainance of existing infrastructure.

See http://www.saxproject.org for more information about SAX.

SAX2 Standard Feature Flags

One of the essential characteristics of SAX2 is that it added feature flags which can be used to examine and perhaps modify parser modes, in particular modes such as validation. Since features are identified by (absolute) URIs, anyone can define such features. Currently defined standard feature URIs have the prefix http://xml.org/sax/features/ before an identifier such as validation. Turn features on or off using setFeature. Those standard identifiers are:

Support for the default values of the namespaces and namespace-prefixes properties is required.

For default values not specified by SAX2, each XMLReader implementation specifies its default, or may choose not to expose the feature flag. Unless otherwise specified here, implementations may support changing current values of these standard feature flags, but not while parsing.

SAX2 Standard Handler and Property IDs

For parser interface characteristics that are described as objects, a separate namespace is defined. The objects in this namespace are again identified by URI, and the standard property URIs have the prefix http://xml.org/sax/properties/ before an identifier such as lexical-handler or dom-node. Manage those properties using setProperty(). Those identifiers are:

All of these standard properties are optional; XMLReader implementations need not support them.

This package contains interfaces to SAX2 facilities that conformant SAX drivers won't necessarily support.

See http://www.saxproject.org for more information about SAX.

This package is independent of the SAX2 core, though the functionality exposed generally needs to be implemented within a parser core. That independence has several consequences:

• SAX2 drivers are not required to recognize these handlers.
• You cannot assume that the class files will be present in every SAX2 installation.
• This package may be updated independently of SAX2 (i.e. new handlers and classes may be added without updating SAX2 itself).
• The new handlers are not implemented by the SAX2 org.xml.sax.helpers.DefaultHandler or org.xml.sax.helpers.XMLFilterImpl classes. You can subclass these if you need such behavior, or use the helper classes found here.
• The handlers need to be registered differently than core SAX2 handlers.

This package, SAX2-ext, is a standardized extension to SAX2. It is designed both to allow SAX parsers to pass certain types of information to applications, and to serve as a simple model for other SAX2 parser extension packages. Not all such extension packages should need to be recognized directly by parsers, however. As an example, most validation systems can be cleanly layered on top of parsers supporting the standardized SAX2 interfaces.

This package contains "helper" classes, including support for bootstrapping SAX-based applications.

See http://www.saxproject.org for more information about SAX.