Administering JNDI Resources

Within GlassFish Server, you can configure your environment for custom and external JNDI resources. A custom resource accesses a local JNDI repository; an external resource accesses an external JNDI repository. Both types of resources need user-specified factory class elements, JNDI name attributes, and so on.

• Administering Custom JNDI Resources

• Administering External JNDI Resources

Administering Custom JNDI Resources

A custom resource specifies a custom server-wide resource object factory that implements the javax.naming.spi.ObjectFactory interface.

The following topics are addressed here:

• To Create a Custom JNDI Resource

• To List Custom JNDI Resources

• To Update a Custom JNDI Resource

• To Delete a Custom JNDI Resource

To Create a Custom JNDI Resource

Use the create-custom-resource subcommand in remote mode to create a custom resource.

1. Ensure that the server is running.

   Remote subcommands require a running server.

2. Create a custom resource by using the create-custom-resource(1) subcommand.

   Information on properties for the subcommand is contained in this help page.

3. Restart GlassFish Server.

   See To Restart a Domain.

Example 18-1 Creating a Custom Resource

This example creates a custom resource named sample-custom-resource.

asadmin> create-custom-resource --restype topic --factoryclass com.imq.topic 
sample_custom_resource
Command create-custom-resource executed successfully.

See Also

You can also view the full syntax and options of the subcommand by typing asadmin help create-custom-resource at the command line.

To List Custom JNDI Resources

Use the list-custom-resources subcommand in remote mode to list the existing custom resources.

1. Ensure that the server is running.

   Remote subcommands require a running server.

2. List the custom resources by using the list-custom-resources(1) subcommand.

Example 18-2 Listing Custom Resources

This example lists the existing custom resources.

asadmin> list-custom-resources
sample_custom_resource01 
sample_custom_resource02 
Command list-custom-resources executed successfully

See Also

You can also view the full syntax and options of the subcommand by typing asadmin help list-custom-resources at the command line.

To Update a Custom JNDI Resource

1. List the custom resources by using the list-custom-resources(1) subcommand.
2. Use the set(1) subcommand to modify a custom JNDI resource.

Example 18-3 Updating a Custom JNDI Resource

This example modifies a custom resource.

asadmin> set server.resources.custom-resource.custom
/my-custom-resource.property.value=2010server.resources.custom-resource.custom
/my-custom-resource.property.value=2010

To Delete a Custom JNDI Resource

Use the delete-custom-resource subcommand in remote mode to delete a custom resource.

1. Ensure that the server is running.

   Remote subcommands require a running server.

2. List the custom resources by using the list-custom-resources(1) subcommand.
3. Delete a custom resource by using the delete-custom-resource(1) subcommand.

Example 18-4 Deleting a Custom Resource

This example deletes a custom resource named sample-custom-resource.

asadmin> delete-custom-resource sample_custom_resource
Command delete-custom-resource executed successfully.

See Also

You can also view the full syntax and options of the subcommand by typing asadmin help delete-custom-resource at the command line.

Administering External JNDI Resources

Applications running on GlassFish Server often require access to resources stored in an external JNDI repository. For example, generic Java objects might be stored in an LDAP server according to the Java schema. External JNDI resource elements let you configure such external resource repositories.

The following topics are addressed here:

• To Register an External JNDI Resource

• To List External JNDI Resources

• To List External JNDI Entries

• To Update an External JNDI Resource

• To Delete an External JNDI Resource

• Example of Using an External JNDI Resource

• To Disable GlassFish Server v2 Vendor-Specific JNDI Names

To Register an External JNDI Resource

Use the create-jndi-resource subcommand in remote mode to register an external JNDI resource.

Before You Begin

The external JNDI factory must implement the javax.naming.spi.InitialContextFactory interface.

1. Ensure that the server is running.

   Remote subcommands require a running server.

2. Register an external JNDI resource by using the create-jndi-resource(1) subcommand.

   Information on properties for the subcommand is contained in this help page.

3. Restart GlassFish Server.

   See To Restart a Domain.

Example 18-5 Registering an External JNDI Resource

In This example sample_jndi_resource is registered.

asadmin> create-jndi-resource --jndilookupname sample_jndi 
--restype queue --factoryclass sampleClass --description "this is a sample jndi resource" sample_jndi_resource
Command create-jndi-resource executed successfully

See Also

You can also view the full syntax and options of the subcommand by typing asadmin help create-jndi-resource at the command line.

To List External JNDI Resources

Use the list-jndi-resources subcommand in remote mode to list all existing JNDI resources.

1. Ensure that the server is running.

   Remote subcommands require a running server.

2. List the existing JNDI resources by using thelist-jndi-resources(1) subcommand.

Example 18-6 Listing JNDI Resources

This example lists the JNDI resources.

asadmin> list-jndi-resources
jndi_resource1
jndi_resource2
jndi_resource3
Command list-jndi-resources executed successfully

See Also

You can also view the full syntax and options of the subcommand by typing asadmin help list-jndi-resources at the command line.

To List External JNDI Entries

Use the list-jndi-entries subcommand in remote mode to browse and list the entries in the JNDI tree. You can either list all entries, or you can specify the JNDI context or subcontext to list specific entries.

1. Ensure that the server is running.

   Remote subcommands require a running server.

2. List the JNDI entries for a configuration by using the list-jndi-entries(1) subcommand.

Example 18-7 Listing JNDI Entries

This example lists all the JNDI entries for the naming service.

asadmin> list-jndi-entries
jndi_entry03
jndi_entry72
jndi_entry76
Command list-jndi-resources executed successfully

See Also

You can also view the full syntax and options of the subcommand by typing asadmin help list-jndi-entries at the command line.

To Update an External JNDI Resource

1. List the existing JNDI resources by using thelist-jndi-resources(1) subcommand.
2. Use the set(1) subcommand to modify an external JNDI resource.

Example 18-8 Updating an External JNDI Resource

This example modifies an external resource.

asadmin> set server.resources.external-jndi-resource.my-jndi-resource.
jndi-lookup-name=bar server.resources.external-jndi-resource.my-jndi-resource.jndi-lookup-name=bar 

To Delete an External JNDI Resource

Use the delete-jndi-resource subcommand in remote mode to remove a JNDI resource.

1. Ensure that the server is running.

   Remote subcommands require a running server.

2. Remove an external JNDI entry by using the delete-jndi-resource(1) subcommand.

Example 18-9 Deleting an External JNDI Resource

This example deletes an external JNDI resource:

asadmin> delete-jndi-resource jndi_resource2
Command delete-jndi-resource executed successfully.

See Also

You can also view the full syntax and options of the subcommand by typing asadmin help delete-jndi-resource at the command line.

Example of Using an External JNDI Resource

<resources>
 <!-- external-jndi-resource element specifies how to access Java EE resources
 -- stored in an external JNDI repository. This example
 -- illustrates how to access a java object stored in LDAP.
 -- factory-class element specifies the JNDI InitialContext factory that
 -- needs to be used to access the resource factory. property element
 -- corresponds to the environment applicable to the external JNDI context
 -- and jndi-lookup-name refers to the JNDI name to lookup to fetch the
 -- designated (in this case the java) object.
 -->
  <external-jndi-resource jndi-name="test/myBean"
      jndi-lookup-name="cn=myBean"
      res-type="test.myBean"
      factory-class="com.sun.jndi.ldap.LdapCtxFactory">
    <property name="PROVIDER-URL" value="ldap://ldapserver:389/o=myObjects" />
    <property name="SECURITY_AUTHENTICATION" value="simple" />
    <property name="SECURITY_PRINCIPAL", value="cn=joeSmith, o=Engineering" />
    <property name="SECURITY_CREDENTIALS" value="changeit" />
  </external-jndi-resource>
</resources>

To Disable GlassFish Server v2 Vendor-Specific JNDI Names

The EJB 3.1 specification supported by GlassFish Server 3.1 defines portable EJB JNDI names. Because of this, there is less need to continue to use older vendor-specific JNDI names.

By default, GlassFish Server v2–specific JNDI names are applied automatically by GlassFish Server 3.1 for backward compatibility. However, this can lead to some ease-of-use issues. For example, deploying two different applications containing a Remote EJB component that exposes the same remote interface causes a conflict between the default JNDI names.

The default handling of v2–specific JNDI names in GlassFish Server 3.1 can be managed with the asadmin command or with the disable-nonportable-jndi-names boolean property for the ejb-container element in glassfish-ejb-jar.xml.

• Use the asadmin command or directly modify the glassfish-ejb-jar.xml file to set the disable-nonportable-jndi-names property.
  • Using the asadmin command:

    asadmin> set server.ejb-container.property.disable-nonportable-jndi-names="true"

  • Directly modifying the glassfish-ejb-jar.xml file.
    1. Add the disable-nonportable-jndi-names property to the ejb-container element in glassfish-ejb-jar.xml.
    2. Set the value of the disable-nonportable-jndi-names boolean, as desired.

       • false — Enables the automatic use of GlassFish Server v2–specific JNDI names. This is the default setting.

       • true — Disables the automatic use of v2–specific JNDI names. In all cases, 3.1-compatible JNDI names will be used.

    3. Save the glassfish-ejb-jar.xml file and restart the GlassFish Server domain.

       This setting applies to all EJBs deployed to the server.