This section describes the procedures involved in editing Java related settings for a selected configuration. See the following links:
This section lets you enable Java and set Java Home variable for the selected configuration.
Editing General Java Settings
Select the Configuration.
Select the configuration from the configuration list. Click Configuration tab to get the list of available configurations.
Click Java > General tab.
The following table describes the parameters available while configuring the general Java settings.
Table 23 Field Description > General Java Settings
Field | Description |
|---|---|
Enable Java | Turn on/off Java support for the configuration. Enabling Java lets the server spawn necessary JVMs. |
Java Home | Location of the Java SE. Specify the absolute path or path relative to the server's config directory. The directory must be owned by the account the server runs as. |
Sticky Attach | Whether the server attaches each HTTP request processing thread to the JVM only once (Otherwise the server attaches/detaches the HTTP request processing thread on each request). |
This section lets you add JVM class path for the selected configuration.
Editing Path Settings
Select the Configuration.
Select the configuration from the configuration list. Click Configuration tab to get the list of available configurations.
Click Java > General tab. Go to Path Settings section.
The following table describes the parameters available while modifying the configuration's JVM path settings.
Table 24 Field Description > Path Settings
Field | Description |
|---|---|
Ignore Environment Class Path | Enabled by default. |
Class Path Prefix | Prefix for the system class path. You should only prefix the system class path if you wish to override system classes, such as the XML parser classes. Use this attribute with caution. |
Server Class Path | Class path containing server classes. Read-Only field. |
Class Path Suffix | Suffix for the system class path. |
Native Library Path Prefix | Prefix for the operating system native library path. |
Bytecode Preprocessor Class | Specify the bytecode preprocessor class. A typical way to perform runtime class instrumentation is through the preprocessing mechanism, whereby profiling and monitoring tools use a class preprocessor to insert instrumentation code at the required places in the Java classes just before they are loaded by the JVM. Toward that end, the class preprocessor works in conjunction with the class loader. |
To set JVM command-line options in the Administration interface, perform the following tasks:
Editing JVM Settings
Select the Configuration.
Select the configuration from the configuration list. Click Configuration tab to get a list.
Click Java > JVM Settings tab.
You can add/delete command line JVM options by specifying the values here. Click Add JVM Option button to add a JVM option.
Some examples for JVM options are:-Djava.security.auth.login.config=login.conf, -Djava.util.logging.manager=com.iplanet.ias.server.logging.ServerLogManager and -Xms128m -Xmx256m
JVM Profiler helps you diagnose and resolve performance problems, memory leaks, multi-threading problems and system resource usage problems in your Java applications to ensure the highest level of stability and scalability for your applications.
You can use a profiler to perform remote profiling on the Sun Java System Web Server to discover bottlenecks in server-side performance.
Adding a New JVM ProfilerSelect the Configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list of available configuration.
Click Java > JVM Settings tab.
Click New button under Profilers section.
Provide values for the following parameters:
Name -- Provide a short name for the new JVM Profiler.
Enabled -- Determines if the profiler is enabled at runtime.
Class path -- Provide a valid class path for the profiler. (Optional).
Native library path -- Provide a valid native library path. (Optional).
JVM Options -- You can specify additional JVM options for the CLI.
For example, --Xrunhprof:file=log.txt,options
HPROF is a simple profiler agent shipped with Java 2 SE. It is a dynamically linked library that interacts with the JVMPI (Java Virtual Machine Profiler Interface) and writes out profiling information either to a file or to a socket in ASCII or binary format. This information can be further processed by a profiler front-end tool.
For more information on various commercial profilers, and their options, see Sun Java System Web Server 7.0 Developer's Guide to Java Web Applications.
The JVM can be started in debug mode and can be attached with a JPDA (Java Platform Debugger Architecture) debugger. When you enable debugging, you enable both local and remote debugging.
Sun Java System Web Server's debugging is based on the JPDA software. To enable debugging, perform the following tasks.
Enable JVM DebuggingSelect the Configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list of available configuration.
Click Java > JVM Settings tab.
Select Enable Debug checkbox under Debug Java Settings.
Provide JVM options as necessary by clicking the New button.
The default JPDA options are as follows:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7.0896 |
If you substitute suspend=y, the JVM starts in suspended mode and stays suspended until a debugger attaches to it. This is helpful if you want to start debugging as soon as the JVM starts. To specify the port to use when attaching the JVM to a debugger, specify address=port_number. Check out the JPDA documentation for a list of debugging options.
This page lets you configure and manage JDBC, Mail, JNDI and other Java based resources.
Web applications may access a wide variety of resources such as resource managers, data sources (for example SQL datasources), mail sessions, and URL connection factories. The J2EE platform exposes such resources to the applications via Java Naming and Directory Interface (JNDI) service.
Sun Java System Web Server allows you to create and manage the following JavaEE resources:
JDBC Datasources.
JDBC Connection Pools.
Java Mail Sessions.
Custom Resources.
External JNDI Resources.
A JDBC Datasource is a Java EE resource that you can create and manage using Sun Java System Web Server.
The JDBC API is the API for connectivity with relational database systems. The JDBC API has two parts:
An application-level interface used by the application components to access databases.
A service provider interface to attach a JDBC driver to the Java EE platform.
A JDBC Datasource object is an implementation of a data source in the Java programming language. In basic terms, a data source is a facility for storing data. It can be as sophisticated as a complex database for a large corporation or as simple as a file with rows and columns. A JDBC datasource is a Java EE resource that can be created and managed via Sun Java System Web Server.
The JDBC API provides a set of classes for Java with a standard SQL database access interface to ensure uniform access to a wide range of relational databases.
Using JDBC, SQL statements can be sent to virtually any database management system (DBMS). It is used as an interface for both relational and object DBMSs.
The following table provides a list of common JDBC drivers and their properties that needs to be configured while adding a new JDBC resource. See Adding a JDBC Resource.
Note - The following list is only a subset of all supported JDBC Drivers.
Table 25 List of common and supported JDBC drivers
Driver | Class Name | Properties |
|---|---|---|
Oracle driver | oracle.jdbc.pool.OracleDataSource |
|
SJS JDBC driver for Oracle | com.sun.sql.jdbcx.oracle.OracleDataSource |
|
DB2 IBM driver | com.ibm.db2.jdbc.DB2DataSource |
|
SJS JDBC driver for DB2 | com.sun.sql.jdbcx.db2.DB2DataSource |
|
MS SQLServer driver | com.ddtek.jdbcx.sqlserver.SQLServerDataSource |
|
SJS JDBC driver for MS | com.sun.sql.jdbcx.sqlserver.SQLServerDataSource |
|
Sybase driver | com.sybase.jdbcx.SybDataSource |
|
SJS JDBC driver for Sybase | com.sun.sql.jdbcx.sybase.SybaseDataSource |
|
MySQL MM driver | org.gjt.mm.mysql.jdbc2.optional.MysqlDataSource |
|
Informix driver | com.informix.jdbcx.IfxDataSource |
|
SJS JDBC driver for Informix | com.sun.sql.jdbcx.informix.InformixDataSource |
|
PostgreSQL driver | org.postgresql.ds.PGSimpleDataSource |
|
Apache Derby driver | org.apache.derby.jdbc.EmbeddedDataSource |
|
Adding a JDBC ResourceSelect the configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Java > Resources tab.
Under JDBC Resources section, click New button.
Select the Driver Vendor.
Specify a unique value for the JNDI name and select the JDBC driver vendor from the available list.
Provide JDBC Resource Properties.
Based on the JDBC driver vendor selection in the previous step, the class name for the driver and the JDBC resource properties are automatically populated. For a list of suggested properties for some common JDBC drivers, see Common JDBC Drivers.
View Summary.
View the summary and Click Finish to create the new JDBC resource.
You can use this option to register a custom resource with the instance of the configuration.
Adding a Custom ResourceSelect the configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Java > Resources tab.
Under Custom Resources section, click New button.
The following table describes the properties available for creating a custom resource.
Table 26 Field Description > Custom Resources
Field | Description |
|---|---|
JNDI Name | Provide a unique JNDI name for the custom resource. |
Custom Resource | Determines if this JDBC resource is enabled at runtime. |
Resource Type | Fully qualified type of this resource. |
Factory Class | Class that instantiates resources of this type. The fully qualified name of the user-written factory class that implements javax.naming.spi.ObjectFactory. |
Description | Provide a short description for the custom resource. |
Properties | Optionally provide CLI properties by clicking Add Property button. |
This option lets you create an external Java Naming and Directory Interface (JNDI) resource. You need an external JNDI resource to access resources stored in an internal JNDI repository.
Adding an External JNDI ResourceSelect the configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Java > Resources tab.
Under External JNDI Resources section, click New button.
The following table describes the properties available while adding a new external JNDI resource.
Table 27 Field Description > External JNDI Resources
Field | Description |
|---|---|
JNDI Name | Provide a unique name for the new external JNDI resource. |
External JNDI Resource | Determines if this external JNDI resource is enabled at runtime. |
External JNDI Name | Name of the external JNDI resource. |
Resource Type | Fully qualified type of this resource. |
Factory Class | Class that instantiates resources of this type. |
Description | Provide a short description for the custom resource. |
Properties | Optionally provide CLI properties by clicking Add Property button. |
JMS destinations are Java EE resources that can be created and managed via Sun Java System Web Server.
Many internet applications require the ability to send email notifications, so the Java EE platform includes the JavaMail API along with a JavaMail service provider that allows an application component to send internet mail.
Adding a New Mail ResourceSelect the Configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Java > Resources tab.
Under Mail Resources section, click New button.
The following table describes the properties available while adding a new mail resource.
Table 28 Field Description > Mail Resource Properties
Field | Description |
|---|---|
JNDI Name | Provide a unique name for the new mail resource. |
Mail Resource | Determines if this mail resource is enabled at runtime. |
Property | Provide values for all required properties like mail.host, mail.from and mail.user. |
Description | Provide a short description for the new mail resource. |
init -- This phase includes reading configuration, initializing built-in subsystems; naming, security and logging services; and creating the web container.
startup -- This phase includes loading and initializing deployed applications
service -- The server is ready to service requests
shutdown -- This phase stops and destroys loaded applications. The system is preparing to shutdown.
termination -- This phase terminates the built-in subsystems and server runtime environment. There won't be any more activity after this phase.
reconfig -- The transient server state in which a server thread is dynamically reconfiguring (while the server is in the service state). This phase can occur several times during the life of the server.
Adding a New Lifecycle ModuleSelect the Configuration.
Select the configuration, from the configuration list. For viewing the list of configuration, click Configuration tab.
Click Java > Lifecycle Modules tab.
Click New button.
Provide values for the following parameters:
Name -- Provide a valid unique name for the new lifecycle module.
Enabled -- If you want to enable this lifecycle module, use this option.
Class Name -- Fully qualified Java class name. The class should implement LifecycleListener interface. For more information on using this interface, refer to the Developer's Guide.
Class Path -- Optional. You can specify a class path for the listener class.
Load Order -- > 100. Order of loading the lifecycle event listeners, in the numerical order. It is recommended to choose a load-order that is greater than or equal to 100 to avoid conflicts with internal lifecycle modules.
On Load Failure -- If this option is enabled, the server does not treat exceptions thrown from the listener classes as fatal thus it continues with the normal startup. Disabled by default.
Description -- Provide a short description about the lifecycle module.
Properties -- Properties can be used to pass arguments to a Java Lifecycle Module. For adding a new property, click Add Property button and enter text for name, value and description.
Caution - The server lifecycle listener classes are invoked synchronously
from the main server thread and hence extra precaution must be taken to ensure
that the listener classes don't block the server. The listener classes may
create threads if appropriate but they must be stopped during the shutdown/termination
phases.
Deleting a Lifecycle ModuleSelect the Configuration.
Select the configuration, from the configuration list. For viewing the list of configuration, click Configuration tab.
Click Java > Lifecycle Modules tab.
Select the lifecycle module and click Delete Lifecycle Module button.
Java Server Lifecycle Modules are Java classes that listen for server lifecycle events in order to perform certain tasks whenever server events like start or stop occur.
The server supports running short or long duration Java based tasks within the web server environment. These tasks get automatically initiated upon server startup and be notified upon server shutdown. So now you can hook up tasks like instantiating singletons, RMI servers, etc.
A brief description of the server's lifecycle is given below:
From this page, you can add and delete authentication realms. The Java EE based security model provides for security realms that identify and authenticate users.
The authentication process verifies users through Java Realm. A realm consists of a set of users, optional group mappings, and authentication logic that can validate authentication requests. Once an authentication request is validated by a configured realm and the security context established, this identity is applied to all subsequent authorization decisions.
The Java Realms are analogous to the auth-dbs (Authentication Databases) with the difference that while auth-dbs are used by the ACL engine (based on rules in your ACL file), the Java Realms are used by the Java Servlet access control rules (specified in each web application's web.xml).
A server instance may have any number of configured realms. The configuration information is present in the auth-realm element in the server.xml file.
The following table defines the different types of realms supported in Sun Java System Web Server 7.0
Table 29 Types of Realms
Realm | Description |
|---|---|
File | The file realm is the default realm when you first install the Sun Java System Web Server. This realm, easy and simple to set up, represents a significant convenience to developers. The file realm authenticates users against user data stored in a text file. Note that unlike the file auth-db, the Java Realm only supports one file format, keyfile. The keyfile format supported by this realm is compatible with the File auth-db keyfile (and both may refer to the same disk file). |
LDAP | The ldap realm allows you to use an LDAP database for user security information. An LDAP directory service is a collection of attributes with unique identifiers. The ldap realm is ideal for deployment to production systems. In order to authenticate users against the ldap realm, you must create the desired user(s) in your LDAP directory. You can do this from the Administration Server's Users & Groups tab. See Editing Users and GroupsYou can also perform this action from your LDAP directory product's user management console. |
PAM | The PAM (aka Solaris) Realm delegates authentication to the Solaris PAM stack. As with the PAM auth-db, this realm is only supported on Solaris 9 and 10 and the server instance must be running as root. |
Certificate | The certificate realm supports SSL authentication. The certificate realm sets up the user identity in the Sun Java System Web Server's security context and populates it with user data from the client certificate. The JavaEE containers then handle authorization processing based on each user's DN from his or her certificate. This realm authenticates users with SSL or TLS client authentication through X.509 certificates. |
Native | The native realm is a special realm that provides a bridge between the core ACL-based authentication model and the Java EE/Servlet authentication model. By using the Native realm for Java web applications it becomes possible to have the ACL subsystem perform the authentication (instead of having the Java web container do so) and yet have this identity available for Java web applications. When an authentication operation is invoked, the Native realm delegates this authentication to the core authentication subsystem. From the user's perspective this is essentially equivalent to, for example, the LDAP realm delegating authentication to the configured LDAP server. When group membership queries are processed by the Native realm, they are also delegated to the core authentication subsystem. From the Java web modules and the developers perspective, the Native realm is no different from any of the other Java realms which are available for use with web modules. |
Custom | Define your own authentication realm. Provide the class that implements a pluggable servlet container authentication realm. |
The following section describes the steps involved in adding a new authentication realm.
Adding a Authentication Realm
Select the configuration.
Select the configuration for which you need to add a new authentication realm. Click Configurations tab and select the configuration.
Click Java > Authentication tab.
Click New under Servlet Authentication.
Provide Realm Details.
Name -- Enter a short name for the realm. This name is used to refer to the realm from, for example, web.xml.
Class -- If you are configuring a custom realm, enter the full Java class name, which implements your custom realm. There is no need to enter a class for any of the built-in realms.
Type -- Select the type of realm. See Table 29
Properties -- Add realm specific properties. For instance property name="file" value="instance_dir/config/keyfile" and property name="jaas-context" value="fileRealm.
Each authentication realm needs required properties to be added. Some required properties are listed in the following table:
Table 30 Required Properties for Authentication Realm
Authentication Realm | Properties |
|---|---|
File |
|
LDAP |
|
PAM | NA |
Certificate |
|
Native |
|
This section describes the procedure for configuring the servlet container.
Editing Servlet Container Settings
Select the configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Java > Servlet Container.
The following table describes the parameters available servlet container page.
Table 31 Field Description > Servlet Container
Field | Description |
|---|---|
Log Level | Log verbosity for the servlet container. The values can be finest (most verbose), finer, fine, info, warning, failure, config, security, or catastrophe (least verbose). |
Dynamic Reload Interval | This parameter defines the time period after which the server checks deployed web applications for modifications. The value range is 1 to 60, or -1 if dynamic reloading should be disabled. |
Anonymous Role | Name of the default, or anonymous, role assigned to all principals. The default role is ANYONE. |
Servlet Pool Size | Number of servlet instances to instantiate per SingleThreadedServlet. The range value is 1 to 4096. |
Dispatcher Max Depth | Maximum depth for the servlet container allowing nested request dispatches. The range of values can be between 0 and 214704836470. The default value is 20. |
Allow Cross Context | Whether request dispatchers are allowed to dispatch to another context. The default value is false. |
Encode Cookies | Whether the servlet container encodes cookie values. The default value is true. |
Display Exceptions | Displays exception on the browser. This option is useful only in development environment. Ensure to disable this option in production environment. |
Decode '+' in cookie value. | Decodes the plus character in cookie value to space. |
Reuse Session IDs | Whether any existing session ID number is reused when creating a new session for that client. The default value is false. |
Secure Session Cookie | This parameter controls under what conditions the JSESSIONID cookie is marked secure. Use dynamic (the default) to mark the cookie secure only when the request was received on a secure connection (HTTPS). Use true to always mark it secure and false to never mark it secure. |
This section describes the procedure for setting up session replication properties for a selected configuration.
Editing Session Replication Settings
Select the configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Java > Session Replication.
The following table describes the parameters available session replication page.
Table 32 Field Description > Session Replication
Field | Description |
|---|---|
Port | Port number where the Administration server is listening. The default port is 8888. |
Enabled | Enable session replication for the selected configuration. |
Encrypted | Whether session data is encrypted prior to replication. The default value is false. |
Cipher | Shared secret that members of the cluster use to authenticate to each other. |
Async | Whether session replication is allowed to occur asynchronously from HTTP request/response processing. The default value is true. |
Getatrribute triggers replication | Whether a call to the HttpSession.getAttribute method should cause a session to be backed up. The default value is true. |
Replica Discovery Max Hops | Maximum number of instances that should be contacted while attempting to find the backup of a session. The range of value is 1 to 214704836470, or -1 for no limit. |
Startup Discovery Timeout | Maximum time (in seconds) that an instance will spend trying to contact its designated backup instance. The range of value is 0.001 to 3600. |
Cookie name | Enter the name of the cookie that tracks which instance owns a session. |
Java Authentication Service Provider Interface for Containers specification defines a standard service provider interface by which authentication mechanism providers may be integrated with containers. You can use the Administration Console to add a new SOAP authentication provider.
Adding a SOAP Authentication Provider
Select the configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Java > Authentication tab.
Under SOAP Authentication section, click New button.
The following table describes the parameters available new SOAP authentication provider page.
Table 33 Field Description > SOAP Authentication Provider
Field | Description |
|---|---|
Name | Enter a short name for the new SOAP authentication provider. |
Class Name | The class that implements the provider. Fully qualified class name of a class that implements javax.security.auth.XXX |
Request Authentication Source | This attribute defines a requirement for message layer sender authentication such as username/password or content authentication such as digital signature to be applied to request messages. The value (auth-policy) may be sender or content. When this argument is not specified, source authentication of the request is not required. |
Request Authentication Recipient | This attribute defines a requirement for message layer authentication of the receiver of a message to its sender, for example, by XML encryption. The values can be before-content or after-content. |
Response Authentication Source | This attribute defines a requirement for message layer sender authentication such as username/password or content authentication such as digital signature to be applied to response messages. The value (auth-policy) may be sender or content. When this argument is not specified, source authentication of the response is not required |
Response Authentication Recipient | This attribute defines a requirement for message layer authentication of the receiver of the response message to its sender, for example, by XML encryption. |
Properties | Provide other CLI properties by clicking Add Property button. |