9-10 Developing Applications for Oracle WebLogic Server
This example references a shared Java EE library with a requirement for the specification version:
library-ref library-namemyLibrarylibrary-name
specification-version2.0specification-version library-ref
In the above example, WebLogic Server looks for matching libraries having a specification version of 2.0 or higher. If multiple libraries are at or above version 2.0,
WebLogic Server examines the selected libraries that use Float values for their implementation version and selects the one with the highest version. Note that
WebLogic Server ignores any selected libraries that have a non-Float value for the implementation version.
This example references a shared Java EE library with both a specification version and a non-Float value implementation version:
library-ref library-namemyLibrarylibrary-name
specification-version2.0specification-version implementation-version81Betaimplementation-version
library-ref
In the above example, WebLogic Server searches for a library having a specification version of 2.0 or higher, and having an exact match of 81Beta for the implementation
version.
The following example requires an exact match for both the specification and implementation versions:
library-ref library-namemyLibrarylibrary-name
specification-version2.0specification-version implementation-version8.1implementation-version
exact-matchtrueexact-match library-ref
The following example specifies a context-root with the library reference. When a WAR library reference is made from weblogic-application.xml, the
context-root may be specified with the reference:
library-ref library-namemyLibrarylibrary-name
context-rootmywebappcontext-root library-ref
9.3.1 Overriding context-roots Within a Referenced Enterprise Library
A Java EE application can override context-roots within a referenced EAR library using entries in the applications weblogic-application.xml deployment
descriptor. Table 9–3
describes the XML elements that override context-root in a library reference.
Creating Shared Java EE Libraries and Optional Packages 9-11
The following example specifies a context-root-override, which in turn, refers to the old context-root specified in one of its libraries and the new context-root
that should be used instead. override:
library-ref library-namemyLibrarylibrary-name
specification-version2.0specification-version implementation-version8.1implementation-version
exact-matchtrueexact-match library-ref
library-context-root-override context-rootwebappcontext-root
override-valuemywebappoverride-value library-context-root-override
In the above example, the current application refers to myLibrary, which contains a Web application with a context-root of webapp. The only way to override this
reference is to declare a library-context-root-override that maps webapp to mywebapp.
9.3.2 URIs for Shared Java EE Libraries Deployed As a Standalone Module
When referencing the URI of a shared Java EE library that was deployed as a standalone module EJB or Web application, note that the module URI corresponds to
the deployment name of the shared Java EE library. This can be a name that was manually assigned during deployment, the name of the archive file that was deployed,
or the name of the exploded archive directory that was deployed. If you redeploy the same module using a different file name or from a different location, the default
deployment name also changes and referencing applications must be updated to use the correct URI.
To avoid this problem, deploy all shared Java EE libraries as Enterprise applications, rather than as standalone modules. If you choose to deploy a library as a standalone
Java EE module, always specify a known deployment name and use that name as the URI in referencing applications.
9.4 Referencing Optional Packages from a Java EE Application or Module
