Previous Contents Index Next
Sun ONE Web Server 6.1 Administrator's Guide

> ## Chapter 12
> Configuring Naming and Resources

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

> This chapter describes the J2EE resources provided by Sun ONE 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 4, "J2EE-based Security for Web Container and Web Applications".

> This chapter includes the following topics:

> - Enabling and Disabling Java
> - Configuring JVM Settings
> - About J2EE Naming Services and Resources
> - About Java Naming and Directory Interface (JNDI)
> - Creating Java-based Resources
> - Modifying Java-based Resources
> - Deleting Java-based Resources

> ##

> Enabling and Disabling Java

> You can enable or disable Java either globally, that is, per instance of Sun ONE Web Server, or for a particular virtual server class. By default, Java is enabled in Sun ONE 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 J2EE directives.

> For more information on the obj.conf and magnus.conf files, see the Sun ONE Web Server 6.1 Administrator’s Configuration File Reference and the Sun ONE Web Server 6.1 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:

> 1. Access the Server Manager and choose the Java tab.
> 2. Click Enable/Disable Servlets/JSP.

> 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 ONE Web Server 6.1 no longer supports the standalone Java Runtime Environment (JRE). Instead, JDK 1.4.1 or higher is 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 ONE Web Server 6.1 Performance Tuning, Sizing, and Scaling Guide.

> ### Configuring General Settings

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

> 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 ONE 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 might want to choose a suffix for the system’s classpath in order to override system classes such as the XML Parser classes, or you might 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:

> 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 ONE 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. Since this is synthesized, it does not appear explicitly in the server configuration.

> 6. Click OK.

> ### Configuring JVM Options

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

> 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 ONE Web Server to discover bottlenecks in server-side performance.

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

> 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 ONE Web Server 6.1 Programmer’s Guide.

> ##

> About J2EE Naming Services and 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 ONE Web Server allows you to create and manage the following J2EE resources:

> - JDBC Datasources
> - JDBC Connection Pools
> - Java Mail Sessions
> - Custom Resources
> - External JNDI Resources

> ### JDBC Datasources

> A JDBC Datasource is a J2EE resource that you can create and manage using Sun ONE 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 J2EE 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 J2EE resource that can be created and managed via Sun ONE 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.

> 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 ONE 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 J2EE resources that can be created and managed via Sun ONE Web Server.

> Many internet applications require the ability to send email notifications, so the J2EE 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:

> - An application-level interface used by the application components to send mail
> - A service provider interface used at the J2EE API level.

> Java Mail Sessions are J2EE resources that can be created and managed via Sun ONE Web Server.

> Note | Sun ONE 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 ONE 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 ONE 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 ONE 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 application programming interface (API) for accessing different kinds of naming and directory services. J2EE components locate objects by invoking the JNDI lookup method.

> This section covers the following topics:

> - J2EE Naming Services
> - Naming References and Binding Information
> - Naming References in J2EE Standard Deployment Descriptor
> - JNDI Connection Factories

> ### J2EE 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 J2EE server. Because J2EE components access this service through the JNDI API, we usually refer to an object's user-friendly name as its JNDI name. For instance, the JNDI name of the Oracle database can be jdbc/Oracle. When it starts up, Sun ONE 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 J2EE 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:

> - The Web application component's business methods access the environment using the JNDI interfaces. The application component provider declares in the deployment descriptor all the environment entries that the application component expects to be provided in its environment at runtime.
> - The container provides an implementation of the JNDI naming context that stores the application component environment. The container also provides the tools that allow the deployer to create and manage the environment of each application component.
> - A deployer uses the tools provided by the container to initialize the environment entries that are declared in the application component's deployment descriptor. The deployer can set and modify the values of the environment entries.
> - The container makes the environment naming context available to the application component instances at runtime. The application component's instances use the JNDI interfaces to obtain the values of the environment entries.

> 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 don't have to change the name in the code. This flexibility also makes it easier for you to assemble J2EE applications from preexisting components.

> The following table lists recommended JNDI lookups and their associated references for the J2EE resources used by Sun ONE Web Server.

> Table 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 J2EE 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 ONE Web Server. This section covers the following topics:

> - Application Environment Entries
> - References to Resources
> - Resource Environment References

> #### Application Environment Entries

> Environment entries, defined using <env-entry>, provide a way of specifying deployment time parameters to J2EE 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 J2EE 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:

> - jdbc/ for a JDBC javax.sql.DataSource factory
> - mail/ for a JavaMail javax.mail.Session factory
> - url/ for a java.net.URL factory

> 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, via 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 ONE Web Server is based primarily on J2EE 1.3, with a few added enhancements.When an application component creates the initial context, via InitialContext(), Sun ONE 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, that is, java:comp/env name space is per Web application and objects bound in one Web application's namespace don't collide with objects bound in other Web applications.

> ### JNDI Connection Factories

> For J2EE 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 J2EE containers. This 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 J2EE 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 ONE Web Server, you can configure the means of accessing the following resources and resource factories:

> - JDBC connection factories
> - JavaMail Session connection factories
> - Generic, custom user-written resource object factories.
> - Support for external resource repositories such as LDAP

> All Sun ONE 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 J2EE resources, and how to access these resources.

> - Creating Java-based Resources
> - Modifying Java-based Resources

> ##

> Creating Java-based Resources

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

> - Creating a New JDBC Connection Pool
> - Creating a JDBC Resource
> - Creating Custom Resources
> - Creating External JNDI Resources

> ### Creating a New JDBC Connection Pool

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

> - Using the Administration Interface
> - Using the Command-Line Interface

> #### Using the Administration Interface

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

> 1. Access the Server Manager and choose the Java tab.
> 2. Click JDBC Connection Pools.
> 3. Click New.

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

> 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 which standard and vendor specific properties 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 then connections will be 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 will incur 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 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
> - Using the Command Line Interface

> #### Using the Administration Interface

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

> 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
> - Using the Command Line Interface

> #### 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
> - Using the Command Line Interface

> #### 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
> - Modifying a JDBC Resource
> - Modifying a Custom Resource
> - Modifying an External JNDI Resource

> ### Modifying a JDBC Connection Pool

> To 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:

> 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:

> 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:

> 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
> - Deleting a JDBC Resource
> - Deleting a JDBC Resource
> - Deleting a JDBC Resource

> ### Deleting a JDBC Connection Pool

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

> - Using the Administration Server
> - Using the Command Line Utility

> ##### Using the Administration Server

> To 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 Command Line Utilities.

> ### Deleting a JDBC Resource

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

> - Using the Administration Server
> - Using the Command Line Utility

> ##### Using the Administration Server

> To delete a JDBC resource using the Administration server:

> 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 Command Line Utilities.

> ### Deleting a Custom Resource

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

> - Using the Administration Server
> - Using the Command Line Utility

> ##### Using the Administration Server

> To delete a custom resource using the Administration server:

> 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 Command Line Utilities.

> ### Deleting an External JNDI Resource

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

> - Using the Administration Server
> - Using the Command Line Utility

> ##### Using the Administration Server

> To delete an external JNDI resource using the Administration server:

> 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 Command Line Utilities.

> Previous Contents Index Next

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.