The following are the web engine tools.

Tools can be used to control and monitor web engines.

Controlling Web Engines

Controlling a web engine includes starting and shutting down the engine. This can be accomplished by using WebAdmin or the console tool.

Monitoring Web Engines

WebAdmin or the console tool can be used to monitor web engines.

The following XML configuration files are related to web engines.

XML schema files are in the 'JEUS_HOME/lib/schemas/jeus/' directory.

The files must start with the XML header defined by JEUS. The root element must specify the namespace of the JEUS XML schema with the existing namespace.

The following are the headers used by each file. The XML header in web.xml is included in the servlet standard.

Web engines can monitor the changes of threads, classes, and sessions. Web engines can also change the monitoring interval.

WebAdmin can be used to set the monitoring interval using the following steps.

When a web context exists for a request, the web context handles any errors that occur.

However, if a web context does not exist, the web engine must handle the error by displaying an error page. In this case, since the default error page might not be in a form suitable for the user, the absolute path to the desired error page can be configured on the web engine.

This configuration is only used for HTTP responses. Only HTML or HTM files can be used, and forwarding is not allowed.

WebAdmin can be used to set the default error page.

This configuration determines whether to display details about the error on the default error page provided by JEUS if an error occurs while a web engine is processing a request. The stack trace details are useful in a development environment, but it is not recommended to display them to the user in the production environment. The configuration can be set in WebAdmin or in jeus-web-dd.xml of each application. For more information about configuring jeus-web-dd.xml, refer to "3.3.1. jeus-web-dd.xml Configurations".

WebAdmin can be used to set the option to attach the stack trace if an error occurs in the following way.

There are three types of encoding configurations that can be used by all contexts in the engine. They can be applied to each application, virtual host, or server by using jeus-web-dd.xml. The xml configurations are applied in the aforementioned order. The administrator can set the encoding in domain.xml by using a tool such as WebAdmin. However, since encoding configuration can vary depending on each web application, it is recommended to set it in jeus-web-dd.xml.

Using WebAdmin

The encoding can be set in WebAdmin using the following steps.

Character Encoding Configurations and Compatibility Guide

JEUS provides encoding configuration in xml to provide application developers with the ease of development and application users or administrators with ease of management. However, in the process of determining and implementing the encoding policy, there arose problems such as the mismatch of "forced" configuration definition between the request and response encodings or the violation of the servlet standard.

Starting from JEUS 7, efforts have been made to improve the consistency and correctness of the encoding policy. This may cause compatibility issues with existing applications. This guide will help modify applications or to use the compatibility option to maintain operation.

Since web engines contain JSP engines, JSPs must be configured by each web engine or each application. For more information, refer to "Chapter 4. JSP Engine".

A user-defined HTTP response header can be defined by using name-value pairs.

The default user-defined header to include in a response can be set in WebAdmin using the following steps.

A policy can be configured for reading a cookie from an HTTP request header or sending a cookie that was created by the application as an HTTP response. The cookie policy can be configured in WebAdmin or in jeus-web-dd.xml by each application.

The cookie policy can be set in WebAdmin using the following steps.

The web engine session settings configure items such as session object sharing, session cookie configurations, and timeouts that are required to manage sessions.

The session configurations can be divided into the following levels.

If sessions are configured at the web engine level, the configurations are shared within the web engine even if they are not configured at the context level. If sessions are configured both at the web engine level and the context level, the context level configurations have a higher precedence. The precedence of the configuration values is context level > web engine level.

If an item is not configured at the context level, the web engine configuration will be used. If neither level contains the configuration, the default value of the web engine will be used.

This section describes how to configure logs.

Configuring Server Logs

For more information about server logs, refer to JEUS Server Guide. "Chapter 8. Logging".

Configuring Access Logs

Web engine access logs can be configured in WebAdmin. Access logs are written to a file by default.

Access logs can be configured in WebAdmin using the following steps.

Configuring Access Logs by Virtual Host

To create access logs by virtual host, the access logs must be configured in each virtual host. For more information, refer to"5.4. Configuring Virtual Hosts".

Formatting Access Logs

The access log format can be configured in WebAdmin. Click [Servers] from the left menu to go to the list of servers. Click a server from the list to go to the server configuration page. On the screen, go to [Engine] > [Web Engine] > [Access Log]. On the Access Log screen, set the 'Format' field. (Refer to [Figure 1.21])

In the format, '%' can be used to express data, and any character strings can be used. Starting from JEUS 7, the Common Log Format (hereafter CLF) is used.

Web engines provide the following format aliases.

The format can be set with an alias from the previous list.

default %S

In this case, the common alias is replaced by the following format and is registered to the web engine.

%h %l %u %t /"%r/" %>s %b %D %S

Format setting can be modified and applied while a service is running. Hence, if the currently running service has a problem, set the debug format to record the session ID and response processing thread name.

Filtering Access Logs Programmatically

Access log filtering is provided to record only logs that meet specific conditions.

JEUS provides the jeus.servlet.logger.AccessLoggerFilter interface and jeus.servlet.logger.AbstractAccessLoggerFilter abstract class.

package jeus.servlet.logger;

import java.util.logging.Filter;
import java.util.logging.LogRecord;

/**
 * This interface provides the information required to filter access logger. 
 * This interface inherits {@link Filter}. It can define various filtering policies in
 * {@link Filter#isLoggable(java.util.logging.LogRecord)} using additionally provided interfaces.
 */
public interface AccessLoggerFilter extends Filter {
    /**
     * Returns the address of the remote client that accesses the server.
     *
     * @param record a LogRecord
     * @return remote client address. Returns null if the address is invalid.
     */
    public String getRemoteAddr( LogRecord record );

    /**
     * Returns the HTTP method of the request, e.g., GET, POST, PUT, etc.
     *
     * @param record a LogRecord
     * @return request method. Returns null if the return value is invalid.
     */
    public String getMethod( LogRecord record );

    /**
     * Returns the URI of the request.
     *
     * @param record a LogRecord
     * @return request uri. Returns null if the uri is invalid.
     */
    public String getRequestURI( LogRecord record );

    /**
     * Returns the response status, e.g., 200, 404
     *
     * @param record a LogRecord
     * @return status.
     */
    public int getStatus( LogRecord record );

    /**
     * Returns the processing duration in milliseconds.
     * @param record a LogRecord
     * @return the processing duration. Returns -1 if the return value is invalid.
     */
    public long getProcessingTimeMillis( LogRecord record );
}

To use filters for certain patterns in the access log, the AccessLoggerFilter interface and AbstractAccessLoggerFilter abstract class can be used to easily implement and apply the filters.

User-created filter classes inherit jeus.servlet.logger.AbstractAccessLoggerFilter interface and must implement the isLoggable() method of the java.util.logging.Filter interface. When implementing the isLoggable() method, use the methods from the jeus.servlet.logger.AccessLoggerFilter API that are needed by the user.

The following example defines a filter class that disables leaving access logs if the request extension is '.gif'.

package sample;

import jeus.servlet.logger.AbstractAccessLoggerFilter;
import java.util.logging.*;

public class SimpleAccessLoggerFilter extends AbstractAccessLoggerFilter {
    public boolean isLoggable(LogRecord record) {
        String requestURI = getRequestURI(record);
        return requestURI != null && !requestURI.endsWith(".gif");
    }
}          

Once the class is defined, compile the class. Add the file to the 'JEUS_HOME/domains/DOMAIN_HOME/lib/application' directory as a JAR file, and configure the filter for the web engine access log. For more information about configuring access logs, refer to "Access log default configurations".

Configuring User Logs

By default, logs are stored in the server log file (JeusServer.log). To use a separate log file, configure a user log. For more information about the default user log file and its location, refer to "1.5. Directory Structure".

Like server logs, user logs can be registered at the JEUS server level as well as in jeus-web-dd.xml for web applications. User logs can be created by each web application or in a specific log file.

User logs can be configured in WebAdmin using the following steps.

As of Servlet 3.0, the number of threads that is required to process an async servlet timeout must be configured.

The async servlet timeout processing can be set in WebAdmin using the following steps.

The properties defined in JEUS can be set in WebAdmin. For more information about web engine properties, refer to JEUS Reference Book. "1.6. Web Engine Properties".

The properties can be set in WebAdmin using the following steps.

Malicious users can attack JEUS by sending a large volume of requests with a large amount of data. When this happens, normal requests can be delayed or fail to receive a response.

To prevent these kinds of attacks, the JEUS administrator can set conditions to determine which requests are malicious and deny them. By default, this is configured in the web engine of the server but can also be set for each listener or connector that receives the request from the web engine. They can be configured in the HTTP listener, WebtoB connector, and AJP13. For more information about configuring each listener or connector, refer to "2.3.1. Common Listener Settings".

Properly configure the following items to prevent web attacks.

The items can be set in WebAdmin using the following steps.

For an example of blocking HTTP requests with a specific URL pattern, let's assume that the HTTP client sent the following request.

GET /examples/%2e%2e%2fdb.txt HTTP/1.1

The web container must URL decode the request URI first.

/examples/../db.txt

By doing this, the user can access files that are not related to the actual HTTP service. Typically, clients with a malicious intent send the request URI in this way.

Since the web container cannot detect all requests with a malicious intent, the user must directly provide settings to prevent malicious patterns. The settings are applied only to HTTP requests and if any match is found within the URI except for the query string, the request is handled as a '404 Not Found' unconditionally.

The setting can be configured in WebAdmin using the following steps.

'Encoded Pattern' is used to check if the URI from the HTTP client contains the specified string. The URI from the client is used after it is URL decoded by the web container. At this time, it is checked whether the 'Decoded Pattern' is included in the URI. Even if one 'Encoded Pattern' is configured, the basic pattern will not be processed. This also applies for the 'Decoded Pattern'.