test

Sun Java System Web Server 6.1 SP12 Administrator's Guide

Chapter 12 Configuring Naming and Resources

The component-based Java™ 2 Platform, Standard Edition (J2SE) technology provides an infrastructure for Web services that simplifies enterprise development and deployment.

This chapter describes the J2SE resources provided by Sun Java System Web Server and discusses the methods used to create and manage these resources.

For a discussion on Java security and realm-based authentication, see Chapter 5, J2SE-based Security for Web Container and Web Applications.

This chapter includes the following topics:

Enabling and Disabling Java

You can enable or disable Java either globally, that is, per instance of Sun Java System Web Server, or for a particular virtual server class. By default, Java is enabled in Sun Java System Web Server and the following line is added to the magnus.conf file:

Init fn=”load-modules” shlib=”<server-root>/bin/https/lib/libj2eeplugin.so”

You can also enable Java for a particular virtual server. When you do so, the server updates the obj.conf file for the virtual server class with the required J2SE directives.

For more information on the obj.conf and magnus.conf files, see the Sun Java System Web Server 6.1 SP12 Administrator’s Configuration File Reference and the Sun Java System Web Server 6.1 SP12 NSAPI Programmer’s Guide.

In some cases, you might want to disable Java either globally or for a particular virtual server class, for example, if your entire server or that class will supply only static content.

To enable or disable Java, do the following

ProcedureTo enable or disable

  1. Access the Server Manager and choose the Java tab.

  2. Click Enable/Disable Servlets/JSP.

    Figure 12–1 The Enable/Disable Servlets/JSP Interface

    The Enable/Disable Servlets/JSP Interface

  3. To enable or disable Java globally, check or uncheck Enable/Disable Java Globally.

    or

    To enable or disable Java for a particular virtual server class, check or uncheck the Enable/Disable Java checkbox corresponding to the virtual server class.

  4. Click OK.

Configuring JVM Settings

Unlike previous releases of the product, the Sun Java System Web Server 6.1 no longer supports the standalone Java Runtime Environment (JRE). Instead, JDK 1.4.1 or higher is a pre-requisite for the server. When you install the server, if you select the default JDK option ,Java Development Kit (JDK) version 1.4.1_03 is installed in the <server-root>/bin/https/jdk directory.

You can configure Java Virtual Machine (JVM) settings for your server instance. These settings include the location of your Java home, compiler options, debugging options, and profiler information. One reason to configure these settings is to improve performance. For more information on performance see the Sun Java System Web Server 6.1 SP12 Performance Tuning, Sizing, and Scaling Guide.

Configuring General Settings

To edit the location of the JDK and to specify debug options perform following steps:

ProcedureTo edit the location of the JDK and to specify debug options

  1. Access the Server Manager and choose the Java tab.

  2. Click JVM General.

    Figure 12–2 The JVM General Interface

    The JVM General Interface

  3. Set the Java Home.

    The Java Home is the path to the directory where the Java Developer’s Kit (JDK) is installed. Sun Java System Web Server supports the Sun JDK 1.4.1_03.

  4. Choose whether to enable debugging and set debug options.

    A list of debug options is available at:

    http://java.sun.com/products/jpda/doc/conninv.html#Invocation

  5. Click OK.

Configuring Path Settings

You might want to configure JVM path settings for certain reasons. For example, you want to choose a suffix for the system’s classpath in order to override system classes such as the XML Parser classes, or you want to ignore the environment classpath to prevent environment variable side effects on a production environment.

To configure the JVM’s path settings in the Administration interface, perform the following tasks

ProcedureTo configure the JVM's path settings in the Administration interface

  1. Access the Server Manager and choose the Java tab.

  2. Click JVM Path Settings.

  3. Choose a suffix for the system’s classpath

  4. Choose whether to ignore the environment classpath.

    If you do not ignore the classpath, the CLASSPATH environment variable is read and appended to the Sun Java System Web Server classpath. The CLASSPATH environment variable is added after the classpathsuffix, at the very end.

    For a development environment, the classpath should be used. For a production environment, this classpath should be ignored to prevent environment variable side effects.

  5. Set a native library path prefix and suffix.

    The native library path is the automatically constructed concatenation of the Web Server installation relative path for its native shared libraries, the standard JRE native library path, the shell environment setting (LD_LIBRARY_PATH on UNIX), and any path specified in the profiler element. It does not appear explicitly in the server configuration, because the native library path is synthesized

  6. Click OK.

Configuring JVM Options

To set JVM command-line options in the Administration interface, perform the following tasks

ProcedureTo set JVM command-line option in the Administration interface

  1. Access the Server Manager, and choose the Java tab.

  2. Click JVM Options and make the necessary changes.

    For information about specific JVM options, see:

    http://java.sun.com/docs/hotspot/VMOptions.html

  3. Click OK.

Configuring the JVM Profiler

You can use a profiler to perform remote profiling on the Sun Java System Web Server to discover bottlenecks in server-side performance.

To configure the JVM Profiler in the Administration interface, perform the following tasks

ProcedureTo configure the JVM Profiler in the Administration interface

  1. Access the Server Manager, and choose the Java tab.

  2. Click JVM Profiler.

  3. Specify the classpath, the native library path, and whether the profiler is enabled.

  4. Add, delete or edit JVM options for the profiler, and click OK.

    For more information about profilers, see the Sun Java System Web Server 6.1 SP12 Programmer’s Guide.

About J2SE Naming Services and Resources

Web applications access a wide variety of resources such as resource managers, data sources (for example SQL datasources), mail sessions, and URL connection factories. The J2SE platform exposes such resources to the applications by using Java Naming and Directory Interface (JNDI) service.

Sun Java System Web Server allows you to create and manage the following J2SE resources:

JDBC Datasources

A JDBC datasource is a J2SE 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:

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 J2SE 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 DBMS. It is used as an interface for both relational and object DBMSs.

For information on creating a custom resource, see Creating a JDBC Resource.

JDBC Connection Pools

A JDBC connection pool is a named group of JDBC connections to a database. These connections are created when the first request for connection is made on the pool when you start Sun Java System Web Server.

The JDBC connection pool defines the properties used to create a connection pool. Each connection pool uses a JDBC driver to establish a connection to a physical database at server start-up.

A JDBC-based application or resource draws a connection from the pool, uses it, and when no longer needed, returns it to the connection pool by closing the connection. If two or more JDBC resources point to the same pool definition, they will be using the same pool of connections at run time.

For information on how to create a new JDBC connection pool, see Creating a New JDBC Connection Pool.

Java Mail Sessions

JMS destinations are J2SE resources that can be created and managed by using Sun Java System Web Server.

Several internet applications require the ability to send email notifications. The J2SE platform includes the JavaMail API along with a JavaMail service provider that allows an application component to send internet mail. The JavaMail API has two parts:

Java Mail Sessions are J2SE resources that can be created and managed by using Sun Java System Web Server.

Note –

Sun Java System Web Server does not provide an Administration Server interface to create Java Mail Sessions. You can use the command line interface to do so. For more information on how you can create a mail resource using the command line utility, see Create Mail Resource.

Custom Resources

A custom resource accesses a local JNDI repository. The customresource element defined in server.xml provides a way of specifying a custom server-wide resource object factory. Such object factories implement the javax.naming.spi.ObjectFactory interface. This element associates a JNDI name (specified through the jndiname sub-element like other Sun Java System Web Server resources) to be used in the server-wide namespace, its type, name of the resource factory class and a set of standard properties used to instantiate the same.

You need to ensure that the resource reference’s environment references are linked to the configured server-wide resources defined using the customresource and externaljndiresource tags in server.xml. Dynamic redeployment of application components is an issue for the JNDI naming environment. Sun Java System Web Server will release all the application specific references and rebind all the new references into the newly installed application’s naming context.

For information on creating a custom resource, see Creating Custom Resources.

External JNDI Resources

Often applications running on Sun Java System Web Server require access to resources stored in an external JNDI repository. For example, generic Java objects could be stored in an LDAP server as per the Java schema. While a custom resource allows you to access a local JNDI repository, to access an external JNDI repository you must use an external JNDI resource. An external JNDI factory must implement the javax.naming.spi.InitialContextFactory interface.

For information on creating an external JNDI resource, see Creating External JNDI Resources.

About Java Naming and Directory Interface (JNDI)

This section discusses the Java Naming and Directory Interface (JNDI), which is an API for accessing different kinds of naming and directory services. J2SE components locate objects by invoking the JNDI lookup method.

This section covers the following topics:

J2SE Naming Services

A JNDI name is a user-friendly name for an object. These names are bound to their objects by the naming and directory service that is provided by a J2SE server. Because J2SE components access this service through the JNDI API, an object’s user-friendly name is its JNDI name. For instance, the JNDI name of the Oracle database can be jdbc/Oracle. When it starts up, Sun Java System Web Server reads information from configuration file and automatically adds JNDI database names to the name space.

The application component’s naming environment is a mechanism that allows customization of the application component’s business logic during deployment or assembly. Use of the application component’s environment allows the application component to be customized without the need to access or change the application component’s source code.

A J2SE container implements the Web application component’s environment, and provides it to the application component instance as a JNDI naming context. The application component’s environment is used as follows:

Each application component defines its own set of environment entries. All instances of an application component within the same container share the same environment entries. Application component instances are not allowed to modify the environment at runtime.

Naming References and Binding Information

A resource reference is an element in a deployment descriptor that identifies the component’s coded name for the resource. More specifically, the coded name references a connection factory for the resource. In the example given in the following section, the resource reference name is jdbc/SavingsAccountDB.

The JNDI name of a resource and the name of the resource reference are not the same. This approach to naming requires that you map the two names before deployment, but it also decouples components from resources. Because of this de-coupling, if at a later time the component needs to access a different resource, you do not have to change the name in the code. This flexibility also makes it easier for you to assemble J2SE applications from preexisting components.

The following table lists recommended JNDI lookups and their associated references for the J2SE resources used by Sun Java System Web Server.

Table 12–1 JNDI Lookups and Their Associated References

JNDI Lookup Name  

Associated Reference  

java:comp/env

Application environment entries 

java:comp/env/jdbc

JDBC DataSource resource 

java:comp/env/mail

JavaMail Session Connection Factories 

java:comp/env/url

URL Connection Factories 

Naming References in J2SE Standard Deployment Descriptor

A naming reference is a string used by the application to look up an object in the given naming context. For each Web application, there is a naming context and the references are configured in the standard component deployment descriptors.This section describes the standard deployment descriptor features used in Sun Java System Web Server. This section covers the following topics:

Application Environment Entries

Environment entries, defined using <env-entry>, provide a way of specifying deployment time parameters to J2SE Web applications. Note that the servlet context initialization parameters could be defined using <context-param>, but <env-entry> is the preferred way because application deployers to configure such applications parameters by explicitly specifying the name, type and values for them.

The following sample describes the syntax of <env-entry> as specified in the J2SE standard deployment descriptors:

<env-entry>
<description> Send pincode by mail </description>
<env-entry-name> mailPincode </env-entry-name>
<env-entry-value> false </env-entry-value>
<env-entry-type> java.lang.Boolean </env-entry-type>
</env-entry>

The <env-entry-type> tag specifies a fully qualified class name for the entry. Here is a code snippet to lookup the <env-entry> using JNDI from a servlet or JSP:

Context initContext = new InitialContext();
Boolean mailPincode = (Boolean)
initContext.lookup("java:comp/env/mailPincode");
// one could use relative names into the sub-context
Context envContext = initContext.lookup("java:comp/env");
Boolean mailPincode = (Boolean)
envContext.lookup("mailPincode");

References to Resources

A factory is an object that creates other objects on demand. A resource factory creates resource objects, such as database connections or message service connections. They are configured using <resource-ref> element in the standard deployment descriptors.

The following example describes the use of factories:

Example

Declaration of a reference to a JDBC connection factory that returns objects of type javax.sql.DataSource:

<resource-ref>
<description> Primary database </description>
<res-ref-name> jdbc/primaryDB </res-ref-name>
<res-type> javax.sql.DataSource </res-type>
<res-auth> Container </res-auth>
</resource-ref>

<res-type> is a fully-qualified class name of the resource factory. The <res-auth> variable can be assigned either Container or Application as a value.

If Container is specified, the web container handles the authentication before binding the resource factory to JNDI lookup registry. If Application is specified, the servlet must handle authentication programmatically. Different resource factories are looked up under a separate sub-context that describes the resource type, follows:

Here is a code snippet to get JDBC connection from an application component with the container handling the authentication:

InitialContext initContext = new InitialContext();
DataSource source =
(DataSource) initContext.lookup("java:comp/env/jdbc/primaryDB");
Connection conn = source.getConnection();

Please note that in order to ensure that for these resource references work, the res-ref-name must map to valid resource factory at runtime.

Resource Environment References

Resource environment references provide a way of accessing, by using JNDI lookups, administered objects associated with a resource. The <resource-env-ref> element, defined in the standard deployment descriptors lets applications declare the resource requirements.

The main difference between <resource-env-ref> and <resource-ref> element is the absence of specific resource authentication requirement, both these elements have to be backed up by a resource factory descriptor.

Examples

<resource-env-ref>
    <description> My Topic </description>
    <res-env-ref-name> jdbc/MyTopic </res-ref-name>
    <res-env-ref-type> javax.jdbc.Topic </res-type>
</resource-env-ref>

Here is a code snippet to access a JMS Topic object:

InitialContext initContext = new InitialContext();

javax.jms.Topic myTopic = (javax.jdbc.Topic) 
initContext.lookup("java:comp/env/jdbc/MyTopic");

Initial Naming Context

The naming support in Sun Java System Web Server is based primarily on J2SE 1.3, with a few added enhancements.When an application component creates the initial context by using InitialContext(), Sun Java System Web Server returns an object that serves as a handle to the Web application’s naming environment. This object in turn provides sub-contexts for the java:comp/env namespace. Each Web application gets its own namespace java:comp/env name space is allotted to each Web application and objects bound in one Web application’s namespace do not collide with objects bound in other Web applications.

JNDI Connection Factories

For J2SE web applications, the deployment descriptor in the web.xml file is the placeholder for defining references to application environment entries or resource manager (such as SQL Data Source) connection factories. Applications look up such references using the JNDI InitialNamingContext provided by the J2SE containers. This feature makes applications portable to different Web Server environments by just making changes to the deployment descriptor, that is, without accessing or modifying the application’s source code.

A connection factory is an object that produces connection objects that enable a J2SE component to access a resource. The connection factory for a database is a javax.sql.DataSource object, which creates a java.sql.Connection object.

In Sun Java System Web Server, you can configure the means of accessing the following resources and resource factories:

All Sun Java System Web Server resource factories are specified within the <resources> </resources> tags in server.xml and have a JNDI name specified using the jndiname attribute (with the exception of jdbconnectionpool which does not have a jndiname). This attribute is used to register the factory in the server-wide namespace. Deployers can map user-specified, application-specific resource reference names (declared within resource-ref or resource-env-ref elements) to these server-wide resource factories using the resource-ref element in sun-web.xml. This enables deployment time decisions to be made with regards to which JDBC resources (and other resource factories) to use for a given application.

A custom resource accesses a local JNDI repository and an external resource accesses an external JNDI repository. Both types of resources need user-specified factory class elements, JNDI name attributes, and so on.

In this section, we will discuss how to create various J2SE resources, and how to access these resources.

Creating Java-based Resources

This section describes how you can use the Administration Interface to create J2SE-based resources:

Creating a New JDBC Connection Pool

You can create a new JDBC connection pools in the following ways:

Using the Administration Interface

To create a new JDBC connection pool using the Administration interface, do the following

ProcedureTo create a new JDBC connection pool using the Administration interface

  1. Access the Server Manager and choose the Java tab.

  2. Click JDBC Connection Pools.

  3. Click New.

    Figure 12–3 The JDBC Connection Pool Interface

    The JDBC Connection Pool Interface

  4. From the Database Vendor drop down, select the type of database that you want to connect to. If your DBMS is not listed, select Other.

    Figure 12–4 The New JDBC Connection Pool Interface

    The New JDBC Connection Pool Interface

  5. Click Next.

    The Add New JDBC Connection Pool page is displayed.

  6. Specify the properties for your new connection pool and click OK.

    Listed below are the connection pool properties that you must specify:

    General

    • Pool Name: Enter a name for the new connection pool.

      • DataSource Classname: The vendor-specific classname that implements the data source. If you selected Other from the Database Vendor list in the New JDBC Connection Pool page, you must enter the vendor-specific classname of the data source you plan to use. Please note that this class must implement javax.sql.DataSource.

        Properties

        Specify standard and proprietary JDBC connection pool properties. Many of these properties are optional. By default the names of all of the standard properties are provided. You will need to consult your database vendor’s documentation to determine the standard and vendor specific properties that are required.

        Pool Settings

      • Steady Pool Size: Specify the minimum number of connections that the pool should maintain. When a connection is given to a requesting thread, it is removed from the pool, reducing the current pool size. The steady pool size also refers to the number of connections that will be added to the pool on server startup.

      • Max Pool Size: Specify the maximum number of connections that can be allowed in the pool at any given point in time.

      • Pool Resize Quantity: When the pool shrinks toward the steady pool size it is resized in batches. This value determines the size of the batch. Making this value too large will delay connection recycling, making it too small will be less efficient.

        Note –

        The pool capacity is only ever increased one connection at a time so this field does not effect increases in pool capacity.

      • Idle Timeout (secs). The maximum time in seconds that a connection can remain idle in the pool. After this time, the pool implementation can close this connection.

      • Max Wait Time (milli secs): The amount of time the caller will wait before getting a connection timeout. The default wait time is long, which means that a caller can wait for a long time. If this value is set to 0, the caller will be blocked until a connection is available.

        Connection Validation

      • Connection Validation Required: If this field is checked connections are validated before they are passed to the application. This allows the web server to automatically re-establish database connections in the case of the database becoming unavailable due to network failure or database server crash. Validation of connections cause additional overhead and slightly reduce performance.

      • Validation Method: Specifies the methods the Web server can employ to validate database connections. Choose from the following values:

        • auto-commit: In this mode, query statements are executed and committed as individual transactions. When auto-commit is disabled, query statements are grouped into transactions that can be terminated by either commit or roll back mechanisms.

        • meta-data: In this mode, a connection’s database is able to provide meta-information describing its tables, its stored procedures, and so on. Each instance of the meta-data object will have a particular query associated with it. The meta-data object will execute that query and cache the results.

        • table: This method requires the Web server to perform a query on a user-specified table.

        Table Name: If you select the validation option, table, from the Validation Method drop-down list, specify the table name here.

      • Fail All Connections: Specifies whether to fail all connections in the pool and re-establish them if a single connection is determined to have failed. If left unchecked, connections will be individually re-established only when they are used.

        Transaction Isolation

        The isolation level that a transaction uses determines how sensitive the application is to changes that other users’ transactions make, and consequently, how long the transaction must hold locks to protect against these changes.

      • Transaction Isolation. Allows you to select the transaction isolation level for this connection. Choose from the following values:

        • read-uncommitted. Also known as dirty read, this isolation level lets a transaction read any data currently on a data page, whether or not that data has been committed.

        • read-committed. This places shared locks on data in such a way that data another transaction has changed but not yet committed will never be read. Because uncommitted data is not read, if a transaction running with read-committed isolation queries the data again, that data might have changed, or additional data might appear that meet the criteria of the original query.

        • repeatable-read. This ensures that locks will be placed on all data that is used in a query. No other user can modify the data that your transaction visits as long as you have not yet committed or rolled back your transaction.

        • serializable. This locks ranges of data so that if a query is reissued, no data will have changed and no additional rows of data will appear during the time interval between the first and second query.

        Guarantee Isolation Level. This ensures that any connection taken from the pool will have the same isolation level. For example, if the isolation level for the connection was changed programatically (for example, con.setTransactionIsolation) when last used, this mechanism will change it back to the specified isolation level.

Using the Command-Line Interface

For information on how to use the command-line interface to create a new JDBC connection pool, see Create JDBC Connection Pool in Appendix A, Command Line Utilities.

Creating a JDBC Resource

A JDBC resource, also called a data source, lets you make connections to a database using getConnection(). Create a JDBC resource in one of these ways:

Using the Administration Interface

To create a JDBC resource using the Administration interface, perform these tasks

ProcedureTo create a JDBC resource using the Administration interface

  1. Access the Server Manager and choose the Java tab.

  2. Click JDBC Resources.

  3. Click the New button.

  4. Enter the following information:

    • JNDI Name (required). Enter the JNDI name that application components must use to access the JDBC resource.

    • Pool Name (required). Select from the list the name (or ID) of the connection pool used by this JDBC resource. For more information, see Creating a New JDBC Connection Pool.

  5. To enable the JDBC resource, select On from the Data Source Enabled drop-down.

    If a JDBC resource is disabled, no application component can connect to it, but its configuration remains in the server instance.

  6. Click OK.

  7. Click Apply Changes.

Using the Command Line Interface

For information on how to use the command-line interface to create a new JDBC resource, see Create JDBC Resource in Appendix A, Command Line Utilities.

Creating Custom Resources

You can create a custom resource in any of the following ways:

Using the Administration Interface

ProcedureTo create custom resources using the administration interface

  1. Access the Server Manager and choose the Java tab.

  2. Click Custom Resources.

  3. Click the New button.

  4. Enter the following information:

    • JNDI Name (required): Enter the JNDI name that application components must use to access the custom resource.

      • Resource Type (required): Enter the fully qualified type of the custom resource.

      • Factory Class (required). Enter the fully qualified name of the user-written factory class, which implements javax.naming.spi.ObjectFactory.

      • Custom Resource Enabled (optional): Select On to enable the custom resource at runtime.

  5. Click OK.

  6. Click Apply Changes.

Using the Command Line Interface

For information on how to use the command-line interface to create a new custom resource, see Create Custom Resource in Appendix A, Command Line Utilities.

Creating External JNDI Resources

You can create an external resource in the following ways:

Using the Administration Interface

ProcedureTo create external JNDI resources using the administration interface

  1. Access the Server Manager and choose the Java tab.

  2. Click External JNDI Resources.

  3. Click the New button.

  4. Enter the following information:

    • JNDI Name (required). Enter the JNDI name that application components must use to access the custom resource.

      • Resource Type (required). Enter the fully qualified type of the custom resource.

      • Factory Class (required). Enter the fully qualified name of the user-written factory class, which implements javax.naming.spi.ObjectFactory.

      • JNDI Lookup (required). Enter the JNDI value to look up in the external repository. For example, if you are creating an external resource to connect to an external repository, to test a mail class, your JNDI Lookup could read cn=testmail.

      • External Resource Enabled (optional). Select On to enable the external resource at runtime.

  5. Click OK.

  6. Click Apply Changes.

Using the Command Line Interface

For information on how to use the command-line interface to create a new custom resource, see Create External JNDI Resource in Appendix A, Command Line Utilities.

Modifying Java-based Resources

This section describes how you can use the Administration interface to modify the properties of the Java-based resources you have created:

Modifying a JDBC Connection Pool

To modify the properties of a JDBC connection pool

ProcedureTo modify the properties of a JDBC connection pool

  1. Access the Server Manager and choose the Java tab.

  2. Click the JDBC Connection Pools link.

  3. Click the link representing the JDBC connection pool you want to edit.

  4. Modify the settings as required.

  5. Click OK.

Modifying a JDBC Resource

To modify the properties of a JDBC resource

ProcedureTo modify the properties of a JDBC resource

  1. Access the Server Manager and choose the Java tab.

  2. Click the JDBC Resources link.

  3. Click the link representing the JDBC resource you want to edit.

  4. Modify the settings as required.

  5. Click OK.

Modifying a Custom Resource

To modify the properties of a custom resource

ProcedureTo modify the properties of a custom resource

  1. Access the Server Manager and choose the Java tab.

  2. Click the Custom Resources link.

  3. Click the link representing the custom resource you want to edit.

  4. Modify the settings as required.

  5. Click OK.

Modifying an External JNDI Resource

To modify the properties of an external JNDI resource

ProcedureTo modify the properties of an external JNDI resource

  1. Access the Server Manager and choose the Java tab.

  2. Click the External JNDI Resources link.

  3. Click the link representing the external JNDI resource you want to edit.

  4. Modify the settings as required.

  5. Click OK.

Deleting Java-based Resources

This section describes how you can use the Administration interface to delete Java-based resources:

Deleting a JDBC Connection Pool

You can delete a JDBC reource using either of the following:

Using the Administration Server

To delete a JDBC connection pool using the Administration Server

ProcedureTo delete a JDBC connection pool using the Administration Server

  1. Access the Server Manager and choose the Java tab.

  2. Click the JDBC Connection Pools link.

  3. Check the checkbox corresponding to the JDBC connection pool you want to delete.

  4. Click OK.

Using the Command Line Utility

For information on the syntax of the command line option you can use, see Appendix A, Command Line Utilities.

Deleting a JDBC Resource

You can delete a JDBC reource using either of the following:

Using the Administration Server

To delete a JDBC resource using the Administration server

ProcedureTo delete a JDBC resource

  1. Access the Server Manager and choose the Java tab.

  2. Click the JDBC Resources link.

  3. Check the checkbox corresponding to the JDBC resource you want to delete.

  4. Click OK.

Using the Command Line Utility

For information on the syntax of the command line option you can use, see Appendix A, Command Line Utilities.

Deleting a Custom Resource

You can delete a custom reource using either of the following:

Using the Administration Server

To delete a custom resource using the Administration server

ProcedureTo delete a custom resource

  1. Access the Server Manager and choose the Java tab.

  2. Click the Custom Resources link.

  3. Check the checkbox corresponding to the custom resource you want to delete.

  4. Click OK.

Using the Command Line Utility

For information on the syntax of the command line option you can use, see Appendix A, Command Line Utilities.

Deleting an External JNDI Resource

You can delete an external JNDI reource using either of the following:

Using the Administration Server

To delete an external JNDI resource using the Administration server, perform the following steps:

ProcedureTo delete an external JNDI resource

  1. Access the Server Manager and choose the Java tab.

  2. Click the External JNDI Resources link.

  3. Check the checkbox corresponding to the external JNDI resource you want to delete.

  4. Click OK.

Using the Command Line Utility

For information on the syntax of the command line option you can use, see Appendix A, Command Line Utilities.