Class loaders in the GlassFish Server runtime follow a delegation hierarchy that is illustrated in the following figure and fully described in Table 2-1.

The following table describes the class loaders in the GlassFish Server.

Table 2-1 Oracle GlassFish Server Class Loaders

In previous GlassFish Server versions, the JVM options provided classpath-prefix and classpath-suffix attributes that made it possible to add JAR files or directories either in front of, or after the application server’s system classpath. These options are not present in GlassFish Server 5.0.

The classpath-prefix was typically used to substitute another package for one of the GlassFish Server packages, for example if a newer one was available. This same result can be achieved by using the Java Endorsed Standards Override Mechanism or on a per-application basis with the --libraries option for the deploy subcommand. For more information, see Using the Endorsed Standards Override Mechanism and the deploy(1) help page, respectively. The Java Optional Package Mechanism does what classpath-suffix used to do. For more information, see Using the Java Optional Package Mechanism.

Note that the class loader hierarchy is not a Java inheritance hierarchy, but a delegation hierarchy. In the delegation design, a class loader delegates class loading to its parent before attempting to load a class itself. If the parent class loader cannot load a class, the class loader attempts to load the class itself. In effect, a class loader is responsible for loading only the classes not available to the parent. Classes loaded by a class loader higher in the hierarchy cannot refer to classes available lower in the hierarchy.

The Java Servlet specification recommends that a web module’s class loader look in the local class loader before delegating to its parent. You can make this class loader follow the delegation inversion model in the Servlet specification by setting delegate="false" in the class-loader element of the glassfish-web.xml file. It is safe to do this only for a web module that does not interact with any other modules. For details, see "class-loader" in GlassFish Server Open Source Edition Application Deployment Guide.

The default value is delegate="true", which causes a web module’s class loader to delegate in the same manner as the other class loaders. You must use delegate="true" for a web application that accesses EJB components or that acts as a web service client or endpoint. For details about glassfish-web.xml, see the GlassFish Server Open Source Edition Application Deployment Guide.

For a number of packages, including java.* and javax.*, symbol resolution is always delegated to the parent class loader regardless of the delegate setting. This prevents applications from overriding core Java runtime classes or changing the API versions of specifications that are part of the Java EE platform.

Optional packages are packages of Java classes and associated native code that application developers can use to extend the functionality of the core platform.

To use the Java optional package mechanism, copy the JAR files into the domain-dir`/lib/ext` directory, or use the asadmin add-library command with the --type ext option, then restart the server. For more information about the asadmin add-library command, see the GlassFish Server Open Source Edition Reference Manual.

For more information, see Optional Packages - An Overview (http://docs.oracle.com/javase/8/docs/technotes/guides/extensions/extensions.html) and Understanding Extension Class Loading (http://docs.oracle.com/javase/tutorial/ext/basics/load.html).

Endorsed standards handle changes to classes and APIs that are bundled in the JDK but are subject to change by external bodies.

To use the endorsed standards override mechanism, copy the JAR files into the domain-dir`/lib/endorsed` directory, then restart the server.

For more information and the list of packages that can be overridden, see Endorsed Standards Override Mechanism (http://docs.oracle.com/javase/8/docs/technotes/guides/standards/).

Access to components within applications and modules installed on the server occurs within the context of isolated class loader universes, each of which has its own Applib and Archive class loaders.

A resource such as a file that is accessed by a servlet, JSP, or EJB component must be in one of the following locations:

You can specify module- or application-specific library classes in one of the following ways:

You can update a library JAR file using dynamic reloading or by restarting (disabling and re-enabling) a module or application. To add or remove library JAR files, you can redeploy the module or application.

Application libraries are included in the Applib class loader. Paths to libraries can be relative or absolute. A relative path is relative to domain-dir`/lib/applibs`. If the path is absolute, the path must be accessible to the domain administration server (DAS). The GlassFish Server automatically synchronizes these libraries to all remote cluster instances when the cluster is restarted. However, libraries specified by absolute paths are not guaranteed to be synchronized.

If multiple applications or modules refer to the same libraries, classes in those libraries are automatically shared. This can reduce the memory footprint and allow sharing of static information. However, applications or modules using application-specific libraries are not portable. Other ways to make libraries available are described in Circumventing Class Loader Isolation.

One library cannot reference classes from another library.

For general information about deployment, including dynamic reloading, see the GlassFish Server Open Source Edition Application Deployment Guide.

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: