Chapter 1. JEUS Web Engines
Prev   Next

Chapter 1. JEUS Web Engines

Table of Contents

1.1. Overview
1.2. Components
1.3. Major Functions
1.4. Management Tools
1.4.1. Types of Tools
1.4.2. Controlling and Monitoring
1.5. Directory Structure
1.6. Environment Configurations
1.6.1. XML Configuration Files
1.6.2. Monitoring
1.6.3. Default Error Page
1.6.4. Stack Trace Attachment
1.6.5. Encoding
1.6.6. JSP Engines
1.6.7. Response Headers
1.6.8. Cookie Policy
1.6.9. Sessions
1.6.10. Logs
1.6.11. Async Servlet Timeout Processing
1.6.12. Web Engine Level Properties
1.6.13. Preventing Web Attacks
1.6.14. Blocking HTTP Requests with a Specific URL Pattern
1.7. Web Engine Tuning

This chapter describes the components and major functions of JEUS web engines and how to configure them.

1.1. Overview

Java EE web applications (hereafter web applications) consist of dynamic web content such as servlets and JSPs, and static resources such as HTML files. TmaxSoft provides JEUS web engines to efficiently handle these web applications.

This chapter introduces JEUS web engines and describes how to control and monitor them in JEUS.

1.2. Components

This section explains the components of web engines and the external resources that interact with web engines.

Web engines are the objects that manage and run web applications that conform to the Java EE, servlet, JSP, and EL standards. Web engines can handle dynamic resources like servlets and JSPs, and static resources like HTML.

Note

A web engine is also known as a web container or a servlet engine.

[Figure 1.1] Web Engine Components

Web Engine Components


The following are the major web engine components.

Note

The context group that was used in JEUS 6 and earlier is no longer used in JEUS 7. Most of the context group functions are provided by the web engine.

The following are the external resources that interact with web engines.

1.3. Major Functions

The following are the major functions of a web engine.

  • Managing web applications

    Web engines can deploy, undeploy, and suspend web applications that conform to the Java EE standards. Web engines can also redeploy web applications while the applications are running to provide seamless service. For more information, refer to "Chapter 3. Web Contexts".

  • Monitoring

    Web engines monitor resource states to respond if problems occur. There are three types of monitoring. Refer to "1.6.2. Monitoring" for more information about configuring each monitoring type.

  • Default error page

    Web engines can set the default error page that will be shown if the context is not ready.

    For more information about this configuration, refer to "1.6.3. Default Error Page".

  • Attaching the stack trace

    Web engines can configure the option to attach the stack trace when an error occurs. For more information about this configuration, refer to "1.6.4. Stack Trace Attachment".

  • Encoding

    Web engines configure the encoding that applies to all registered contexts. For more information about the configuration, refer to "1.6.5. Encoding".

  • JSP engines

    All web engines contain JSP engines. When clients request JSP resources, the JSP engine converts the JSP pages to Java files, and then compiles the Java files to create the servlet byte code. This process creates Java files and class files for each JSP.

    For more information about this configuration, refer to "4.4. Configuring JSP Engines".

  • Response headers

    Web engines can configure name-value pairs for user defined HTTP response headers. If a response header is set, the defined header will be included in all responses from the web engine.

    For more information about this configuration, refer to "1.6.7. Response Headers".

  • Managing sessions

    Web engines can configure session management. All configurations related to sessions such as clustered session participation, session object sharing, session cookie configuration, and timeouts can be set. For more information about the configurations, refer to "1.6.9. Sessions" and JEUS Session Management Guide. "Chapter 1. Session Tracking".

  • Logging events

    Web engines create server logs and access logs. Web applications create user logs using servlet context log method.

    ClassificationDescription
    Server logsWeb engine operation logs.
    Access logsRequest and result logs.
    User logsLogs that were created in web applications through the javax.servlet.ServletContext.log(String msg) or javax.servlet.ServletContext.log(String msg, Throwable t) methods.

    For information about the default paths of JEUS logs, refer to "1.5. Directory Structure". For more information about the log configuration, refer to "1.6.10. Logs".

  • Graceful Shutdown

    This function guarantees the completion of running services if an administrator shuts down a JEUS server. If the administrator executes the shutdown command, the following two actions occur:

    1. The server will no longer receive requests.

    2. Services that are already running will complete and then shutdown will continue.

    If the services that are already running take too long to complete, JEUS can set the timeout option when running the shutdown command. For more information about graceful shutdown, refer to JEUS Server Guide. "3.1.3. Shutting Down a Managed Server".

    Note

    The shutdown-timeout configuration that was provided by JEUS 6 is no longer available. Instead, the same function is provided if the shutdown timeout option is configured through the console tool (jeusadmin).

  • Handling web attacks

    Web engines provide settings that prevent attacks like denial of service (DoS).

    The limits for the POST request size, the number of parameters included in GET and POST requests, the number of headers included in a request, the size of headers included in a request, and the query string size of a GET request can be configured. For more information about these settings, refer to "1.6.13. Preventing Web Attacks".

1.4. Management Tools

This section describes the tools that control and monitor web engines.

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.

1.5. Directory Structure

The following is the directory structure of JEUS web engines.

[Figure 1.4] Web Engine Directory Structure

Web Engine Directory Structure


JEUS_HOME

JEUS installation home directory.

domains/domain1/config/

The domains directory in JEUS_HOME contains a directory for each domain name. The web engine configuration files are in the config directory, and domain1 is a domain name used as an example.

Domain.xml is an integrated configuration file that contains all server configurations for the domain. Web engines can also be configured by each server.

Note

1. For more information about domain.xml, refer to "JEUS Server Guide".

2. As of JEUS 7, WEBMain.xml is no longer used.

3. As of JEUS 7, there is a separate JVM for each web engine, so a configuration directory for each engine is not needed.

  • servlet/

    This directory contains the XML configuration file that is used by all servers in the domain when deploying web applications.

    FileDescription
    web.xmlAs of Servlet 3.0, web.xml is not needed, but since Tomcat Jasper, a JSP parser, checks the application version based on the file, it is recommended to keep the file. Web applications that do not contain web.xml will also use this file.
    webcommon.xmlShared configuration file that applies to all web applications. The file type is same as web.xml.

    Note

    When servers in the domain start, they receive web.xml and webcommon.xml from the Domain Administration Server to maintain synchronization.

  • servlet/server1/

    If webcommon.xml and web.xml exist in the servlet configuration directory, the files only apply to that server. This configuration has a higher precedence than those in the parent directories.

    Note

    If web.xml or webcommon.xml exists in a server directory, they are not managed automatically by JEUS, so the server administrator must manage the files manually.

domains/domain1/servers/server1/logs

Files that have been created while a server is running in the domain are created in the server specific directory of the server directory. For more information, refer to JEUS Server Guide. "Chapter 8. Logging".

Log files are created in the logs directory. Logs created by web engines are stored in JeusServer.log. The file name can change due to log rotation, but it is initially set to JeusServer.

  • servlet/

    This directory contains the web application access log, access.log.

    If access logs are created by each virtual host in this directory, directories will be created with the virtual host names and the access logs will be stored in the corresponding directory. For more information, refer to "Chapter 5. Virtual Hosts".

    This directory also contains the user.log or user_appname.log file that contains logs created through the log method of the ServletContext API. User logs can be stored in user.log or in a separate file, user_appname.log, depending on the configuration.

1.6. Environment Configurations

This section describes environment and web engine configuration files.

It is recommended to use WebAdmin to configure web engines. The following knowledge is required to configure web engines in WebAdmin.

Note

For more information about how to use WebAdmin, refer to "JEUS WebAdmin Guide".

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.

Note

All tags used in this guide are written in the same order as the XML schema. Since it is not easy to maintain the order, JEUS provides a sorting function that automatically orders the tags. Users do not need to maintain the order when editing an XML configuration file. Refer to "JEUS XML Reference" for more information about the configuration order.

In the previous examples, the standard header is omitted for readability. Actual XML configuration files contain the standard header.

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.

  1. 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] > [Basic].

    [Figure 1.7] Configuring Monitoring - Menus

    Configuring Monitoring - Menus

  2. Click [Lock & Edit] to change to configuration mode.

  3. In the Advanced Options section of the Web Engine configuration screen, configure each item in the Monitoring section and click [OK].

    [Figure 1.8] Configuring Monitoring - Configuration

    Configuring Monitoring - Configuration


    The following describes each option in the Monitoring section.

    ItemDescription
    Check Thread PoolInterval for checking worker thread states in the worker thread pool. The default value is 300000 (5 minutes).
    Check Class Reload

    Interval for checking if each class has been modified for automatic web context reloading. The default value is 300000 (5 minutes).

    This configuration is used when <auto-reload><enable-reload> in jeus-web-dd.xml is configured. This does not check web applications for which <check-on-demand> is set to true.

    Check Session

    Interval for checking the timeout state of each session. The timeout states of sessions are defined in the web.xml file of the web engine or context.

    The default value is 300000 (5 minutes).

  4. After completing the configurations, click [Apply Changes] to apply the changes to the server. (Refer to [Figure 1.5])

  5. The following result is displayed. Since the monitoring configurations cannot be applied dynamically, the server must be restarted to apply the changes.

    [Figure 1.9] Configuring Monitoring - Result

    Configuring Monitoring - Result

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.

  1. Click [Servers] from the left menu to see the server list. Click a server from the list to go to the server configuration page. On the screen, go to [Engine] > [Web Engine] > [Basic]. (Refer to [Figure 1.7])

  2. Click [Lock & Edit] to change to configuration mode.

  3. On the Web Engine screen, enter the absolute path to the error page in 'Default Error Page' and click [OK].

    [Figure 1.10] Default Error Page - Configuration

    Default Error Page - Configuration

  4. After completing the configurations, click [Apply Changes]. (Refer to [Figure 1.5])

  5. The following result is displayed. Since the 'Default Error Page' configuration cannot be applied dynamically, the server must be restarted to apply the changes.

    [Figure 1.11] Default Error Page - Result

    Default Error Page - Result

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.

  1. Click [Servers] from the left menu to see the server list. Click a server from the list to go to the server configuration page. On the screen, go to [Engine] > [Web Engine] > [Basic]. (Refer to [Figure 1.7])

  2. Click [Lock & Edit] to change to configuration mode.

  3. On the Web Engine screen, set 'Attach Stacktrace On Error' as true or false and then click [OK]. The default value is false. If it is set to true and 'Default Error Page' is not set, the stack trace will be attached to the default error page of the web engine.

    For more information about configuring the default error page, refer to "1.6.3. Default Error Page".

    [Figure 1.12] Configuring Stack Trace Attachment - Configuration

    Configuring Stack Trace Attachment - Configuration

  4. After completing the configuration, click [Apply Changes] to apply the changes. (Refer to [Figure 1.5])

  5. The following result is displayed. Since the 'Attach Stacktrace On Error' configuration cannot be applied dynamically, the server must be restarted to apply the changes.

    [Figure 1.13] Configuring Stack Trace Attachment - Result

    Configuring Stack Trace Attachment - Result

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.

Since JSP Page Character Encoding is strictly related to JSP file settings, the <response-encoding> forced setting cannot replace file encoding.

The following precedence order is used to read a JSP file.

JSP Page Character Encoding > forced > JSP Response Character Encoding > default

The previous precedence order shows that the file encoding used by the file system to read a JSP file has a higher precedence than the one used by the HTTP response created from the JSP. For detailed information about the JSP Page Character Encoding and Response Character Encoding, refer to the JSP standard or the following guide.

Using WebAdmin

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

  1. 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] > [Basic]. (Refer to [Figure 1.7])

  2. Click [Lock & Edit] to change to configuration mode.

  3. In the Encoding section of the Advanced Options, set 'Request URL Encoding', 'Request Encoding', 'Response Encoding' and click [OK].

    Except for 'Request URL Encoding', the configurations can also be set in jeus-web-dd.xml.

    [Figure 1.14] Web Engine Encoding - Configuration

    Web Engine Encoding - Configuration

    Select either 'Default' or 'Forced' and enter the encoding name.

    ValueDescription
    DefaultUse the default value if no encoding is specified.
    ForcedAlways use the encoding.

  4. After completing the configurations, click [Apply Changes] to apply the changes. (Refer to[Figure 1.5])

  5. The following result is displayed. Since the encoding configurations cannot be applied dynamically, the server must be restarted to apply the changes.

    [Figure 1.15] Web Engine Encoding - Result

    Web Engine Encoding - Result

Note

In JEUS 6 and earlier versions, both <default> and <forced> could be set, but only the <forced> setting will be applied overriding the <default> setting. Starting from JEUS 7, only one of <default> or <forced> can be set.

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.

Note

It is recommended to configure the compatibility option in jeus-web-dd.xml. If it is configured in domain.xml of each server, it affects all applications deployed to the server.

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.

  1. Click [Servers] from the left menu to go 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] > [Basic]. (Refer to [Figure 1.7])

  2. Click [Lock & Edit] to change to configuration mode.

  3. Configure the items in the Response Header section of Advanced Options and click [OK].

    The following example sets two user-defined response headers. When setting more than one response header, put each pair on a separate line, and separate each header name and value with a '='.

    [Figure 1.16] Web Engine Response Headers - Configuration

    Web Engine Response Headers - Configuration

    A following describes each option.

    OptionDescription
    Custom HeaderDefines the custom field that will be added to HTTP responses.

  4. After completing the configuration, click [Apply Changes] to apply the changes. (Refer to[Figure 1.5])

  5. The following result is displayed. Since the 'Custom Header' configuration cannot be applied dynamically, the server must be restarted to apply the changes.

    [Figure 1.17] Web Engine Response Headers - Result

    Web Engine Response Headers - Result

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.

  1. Click [Servers] from the left menu to go 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] > [Basic]. (Refer to [Figure 1.7])

  2. Click [Lock & Edit] to change to configuration mode.

  3. In Advanced Options, configure the Cookie Policy section and click [OK].

    The following example sets the cookie encoding to UTF-8 as a cookie policy.

    [Figure 1.18] Web Engine Cookie Policy - Configuration

    Web Engine Cookie Policy - Configuration

    ConfigurationDescription
    Apply URL Encoding RuleOption to apply the URL encoding rule.
    Charset EncodingCharset encoding that is used when cookies are used for a response or interpretation regardless of whether the URL encoding rule will be applied. If not set, the request encoding will be used.

  4. After completing configurations, click [Apply Changes] to apply the changes. (Refer to[Figure 1.5])

  5. The following result is displayed. Since the cookie policy settings cannot be applied dynamically, the server must be restarted to apply the changes.

    [Figure 1.19] Web Engine Cookie Policy - Result

    Web Engine Cookie Policy - Result

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.

  • Context level

    Sessions are configured in the <jeus-web-dd> element of jeus-web-dd.xml.

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.

Note

For more information about sessions in a clustered environment, refer to JEUS Session Management Guide. "Chapter 1. Session Tracking".

This section describes how to configure logs.

  • Configuring server logs

  • Configuring access logs

  • Configuring access logs by virtual hosts

  • Formatting access logs

  • Filtering access logs

  • Configuring user 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.

Note

As of JEUS v6.0 Fix #8, the access logs are set to use log rotation by default.

Log rotation saves the log file with a new name when the file exceeds a specified size or at a specified time, and records new logs in the existing file.

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

  1. 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].

    [Figure 1.20] Web Engine Access Logs - Menus

    Web Engine Access Logs - Menus

  2. Click [Lock & Edit] to change to configuration mode.

  3. Configure the items, or simply use the default values. The access log format and whether to exclude certain file extensions can be configured. Use the Handlers section to add a handler other than the default file handler. For more information about handlers, refer to JEUS Server Guide. "Chapter 8. Logging".

    The following is an example of changing the access log format from the default format to a customized one.

    [Figure 1.21] Web Engine Access Logs - Configuration

    Web Engine Access Logs - Configuration

    Descriptions of each item in Advanced Options follow:

    OptionDescription
    Filter ClassFilter class of the logger.
    Formatter ClassFormatter class name of the logger handler.

  4. After completing the configurations, click [Apply Changes] to apply the changes. (Refer to [Figure 1.5])

  5. The following result is displayed. Since some access log configurations cannot be applied dynamically, the server must be restarted to apply the changes.

    [Figure 1.22] Web Engine Access Logs - Result

    Web Engine Access Logs - Result

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.

Note

1. For more information about CLF, refer to http://httpd.apache.org/docs/2.0/logs.html.

2. For more information about changing the format using the console tool, refer to JEUS Reference Book. "4.2.8.19. modify-web-engine-configuration".

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.

Note

1. Requests can be filtered by file extension using <exclude-ext>.

2. Starting from JEUS 7, the package jeus.servlet.util has been changed to jeus.servlet.logger.

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

[Example 1.7] Definition of jeus.servlet.logger.AccessLoggerFilter Interface

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'.

[Example 1.8] Example of Defining a Filter Class

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.

  1. The access log format can be configured in WebAdmin. Click [Servers] on 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 [Basic] > [User Logging].

  2. Click [Lock & Edit] to change to configuration mode.

  3. To create logs only for a web application named webapp, set 'Name' as in the following. If 'jeus.systemuser' is entered without the name webapp, the user logs are configured for all web applications. For more information about each item in the Advanced Options section, refer to "Access log default configurations". The 'Level' and Advanced Options can be optionally set as needed.

    [Figure 1.23] User Logs - Configuration

    User Logs - Configuration


  4. After configure the log name, click [OK]. Buttons for adding a handler will appear below the Handlers section. Click one of [FILE HANDLER], [SMTP HANDLER], [SOCKET HANDLER] or [USER HANDLER]. For more information about configuring handlers, refer to JEUS Server Guide. "Chapter 8. Logging".

    This example uses [FILE HANDLER].

    [Figure 1.24] User Logs - Adding a Handler

    User Logs - Adding a Handler


  5. Configure each item on the File Handler screen and then click [OK] to add the handler.

    [Figure 1.25] User Logs - Configuring the Handler

    User Logs - Configuring the Handler


  6. The following message will be displayed to confirm that the handler has been added.

    [Figure 1.26] User Logs - Handler Added

    User Logs - Handler Added

  7. After completing the configurations, click [Apply Changes] to apply the changes. (Refer to [Figure 1.5])

  8. The following result is displayed. Since the user log configurations cannot be applied dynamically, the server must be restarted to apply the changes.

    [Figure 1.27] User Logs - Result

    User Logs - Result


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.

  1. 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] > [Basic]. (Refer to [Figure 1.7])

  2. Click [Lock & Edit] to change to configuration mode.

  3. On the Web Engine screen, set 'Async Timeout Min Threads' and click [OK].

    [Figure 1.28] Async Servlet Timeout Processing - Configuration

    Async Servlet Timeout Processing - Configuration


  4. After completing the configuration, click [Apply Changes] to apply the changes (Refer to [Figure 1.5])

  5. The following result is displayed. Since the async servlet timeout configuration cannot be applied dynamically, the server must be restarted to apply the changes.

    [Figure 1.29] Async Servlet Timeout Process - Result

    Async Servlet Timeout Process - Result


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.

  1. 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] > [Basic]. (Refer to [Figure 1.7])

  2. Click [Lock & Edit] to change to configuration mode.

  3. Set the 'Properties' as in the following. Separate the property name and value with a "=". Enter each property on a new line. After entering all the properties, click [OK].

    [Figure 1.30] Web Engine Properties - Configuration

    Web Engine Properties - Configuration

    Note

    It is recommend to use WebAdmin to set the 'Properties', but the properties can also be set in 'Jvm Option' from [Servers] > [Basic] > [Basic Info].

  4. After completing the configuration, click [Apply Changes] to apply the changes. (Refer to [Figure 1.5])

  5. The following result is displayed. Since the properties cannot be applied dynamically, the server must be restarted to apply the changes.

    [Figure 1.31] Web Engine Properties - Result

    Web Engine Properties - Result


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.

  1. 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] > [Web Connections]. A list of web connections will be displayed. Click a web connection from the list.

    [Figure 1.32] Preventing Web Attacks - Menu

    Preventing Web Attacks - Menu

  2. Click [Lock & Edit] to change to configuration mode.

  3. In Advanced Options, configure each item in the Http Listener section. Each listener can use these settings to prevent web attacks.

    For more information about each configuration item, refer to"2.3.1. Common Listener Settings".

    [Figure 1.33] Preventing Web Attacks - Advanced Options

    Preventing Web Attacks - Advanced Options


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.

Note

This setting was configured in the property file from JEUS 6 to JEUS v7.0 Fix#1, but starting from JEUS v7.0 Fix#2, it is configured in domain.xml.

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

  1. Select [Servers] from the left menu of WebAdmin to go to the server list screen. Select a server to start and go to the server configuration screen. Select [Engine] > [Web Engine] to go to the basic configuration search screen, and then scroll down to the advanced options section.

  2. To set or modify the configuration, click [Lock & Edit] on the left to change to configuration mode.

  3. Configure Blocked Url Patterns as in the following.

    [Figure 1.34] Prevention of Requesting HTTP with the URL Pattern - Advanced Options Settings

    Prevention of Requesting HTTP with the URL Pattern - Advanced Options Settings

'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'.

Note

If no configuration exists, the web container processes %2e, %2f, %5c, %23, and %00 as 404 in case of an Encoded Pattern and # as 404 in case of a Decoded Pattern.

Patterns are not case-sensitive. They are always converted to lower case letters before being processed.

1.7. Web Engine Tuning

Consider the following items for the best web engine performance.

  • Set <output-buffer-size> to an appropriate size. If using with WebtoB, set appropriate values for <send-buffer-size> and <receive-buffer-size> inside <webtob-connector><webtob-connector>.

  • Set <check-included-jspfile> to 'false' unless the included JSPs have been modified. If it is set to false, the included JSP files will not be checked for modification to improves performance.

  • If the JSP files have not been modified, the jeus.servlet.jsp.reload property is set to false. This prevents querying the metadata from the file system on every JSP call.

Prev   Next
About This Document Home Chapter 2. Web Connection Management