Part I Development Tasks and Tools
1. Setting Up a Development Environment
Using the Java Optional Package Mechanism
Using the Endorsed Standards Override Mechanism
Application-Specific Class Loading
Circumventing Class Loader Isolation
Packaging the Client JAR for One Application in Another Application
To Package the Client JAR for One Application in Another Application
3. Using Ant with Enterprise Server
Part II Developing Applications and Application Components
7. Using the Java Persistence API
8. Developing Web Applications
9. Using Enterprise JavaBeans Technology
10. Using Container-Managed Persistence
13. Developing Lifecycle Listeners
Part III Using Services and APIs
14. Using the JDBC API for Database Access
15. Using the Transaction Service
16. Using the Java Naming and Directory Interface
Since each application or individually deployed module class loader universe is isolated, an application or module cannot load classes from another application or module. This prevents two similarly named classes in different applications or modules from interfering with each other.
To circumvent this limitation for libraries, utility classes, or individually deployed modules accessed by more than one application, you can include the relevant path to the required classes in one of these ways:
To use the Common class loader, copy the JAR files into the domain-dir/lib or as-install/lib directory or copy the .class files (and other needed files, such as .properties files) into the domain-dir/lib/classes directory, then restart the server.
Using the Common class loader makes an application or module accessible to all
applications or modules deployed on servers that share the same configuration. However, this
accessibility does not extend to application clients. For more information, see
Using Libraries with Application Clients.
For example, using the Common class loader is the recommended way of adding
JDBC drivers to the Enterprise Server. For a list of the JDBC drivers
currently supported by the Enterprise Server, see the
Sun GlassFish Enterprise Server v3 Release Notes. For configurations of supported and
other drivers, see
Configuration Specifics for JDBC Drivers in Sun GlassFish Enterprise Server v3 Administration Guide.
To activate custom login modules and realms, place the JAR files in the domain-dir/lib directory or the class files in the domain-dir/lib/classes directory, then restart the server.
By packaging the client JAR for one application in a second application, you allow an EJB or web component in the second application to call an EJB component in the first (dependent) application, without making either of them accessible to any other application or module.
As an alternative for a production environment, you can have the Common class
loader load the client JAR of the dependent application as described in
Using the Common Class Loader. Restart
the server to make the dependent application accessible to all applications or modules
deployed on servers that share the same configuration.
Deploy the dependent application.
Add the dependent application’s client JAR file to the calling application.
For a calling EJB component, add the client JAR file at the same level as the EJB component. Then add a Class-Path entry to the MANIFEST.MF file of the calling EJB component. The Class-Path entry has this syntax:
Class-Path: filepath1.jar filepath2.jar ...
Each filepath is relative to the directory or JAR file containing the MANIFEST.MF file. For details, see the Java EE specification.
For a calling web component, add the client JAR file under the WEB-INF/lib directory.
If you need to package the client JAR with both the EJB and web components, set delegate="true" in the class-loader element of the sun-web.xml file.
This changes the Web class loader so that it follows the standard class loader delegation model and delegates to its parent before attempting to load a class itself.
For most applications, packaging the client JAR file with the calling EJB component is sufficient. You do not need to package the client JAR file with both the EJB and web components unless the web component is directly calling the EJB component in the dependent application.
Deploy the calling application.
The calling EJB or web component must specify in its sun-ejb-jar.xml or sun-web.xml file the JNDI name of the EJB component in the dependent application. Using an ejb-link mapping does not work when the EJB component being called resides in another application.
You do not need to restart the server.