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
Any Java EE archive JAR, WAR, RAR, EAR can reference one or more registered optional packages using attributes in the archives manifest file.
Table 9–3 weblogic-application.xml Elements for Overriding a Shared Java EE Library
Element Description
context-root An optional String value that overrides the context-root elements declared in
libraries. In the absence of this element, the librarys context-root is used. Only a referencing application for example, a user application can override the
context-root elements declared in its libraries. override-value
An optional String value that specifies the value of the library-context-root-override element when overriding the context-root
elements declared in libraries. In the absence of these elements, the librarys context-root is used.
9-12 Developing Applications for Oracle WebLogic Server
For example, this simple entry in the manifest file for a dependent archive references two optional packages, myAppPkg and my3rdPartyPkg:
Extension-List: internal 3rdparty internal-Extension-Name: myAppPkg
3rdparty-Extension-Name: my3rdPartyPkg
This example requires a specification version of 2.0 or higher for myAppPkg: Extension-List: internal 3rdparty
internal-Extension-Name: myAppPkg 3rdparty-Extension-Name: my3rdPartyPkg
internal-Specification-Version: 2.0
Table 9–4 Manifest Attributes for Referencing Optional Packages
Attribute Description
Extension-List logical_name [...]
A required String value that defines a logical name for an optional package dependency. You can use multiple values in the Extension-List attribute to
designate multiple optional package dependencies. For example: Extension-List: dependency1 dependency2
[logical_name-]Extension-Name A required string value that identifies the name of an optional package dependency. This value must match the Extension-Name attribute defined in
the optional packages manifest file. If you are referencing multiple optional packages from a single archive,
prepend the appropriate logical name to the Extension-Name attribute. For example:
dependency1-Extension-Name: myOptPkg [logical_
name- ]Specification-Version
An optional String value that defines the required specification version of an optional package. If this element is not set, the archive uses a matching
package with the highest specification version. If you include a specification-version value using the majorminor version format, the
archive uses a matching package with the highest specification version that is not below the configured value. If all available package are below the
configured specification-version, the archive cannot be deployed.
If you specify a String value that does not use majorminor versioning conventions for example, 9.2BETA the archive requires a matching optional
package having the exact same string value in the Specification-Version attribute in the packages manifest file. See
Table 9–2 .
If you are referencing multiple optional packages from a single archive, prepend the appropriate logical name to the Specification-Version
attribute. [logical_
name- ]Implementation-Version
An optional String value that specifies the required implementation version of an optional package. If this element is not set, the archive uses a matching
package with the highest implementation version. If you specify a string value using the majorminor version format, the archive uses a matching package
with the highest implementation version that is not below the configured value. If all available libraries are below the configured
implementation-version, the application cannot be deployed.
If you specify a String value that does not use majorminor versioning conventions for example, 9.2BETA the archive requires a matching optional
package having the exact same string value in the Implementation-Version attribute in the packages manifest file. See
Table 9–2 .
If you are referencing multiple optional packages from a single archive, prepend the appropriate logical name to the Implementation-Version
attribute.
Creating Shared Java EE Libraries and Optional Packages 9-13
This example requires a specification version of 2.0 or higher for myAppPkg, and an exact match for the implementation version of my3rdPartyPkg:
Extension-List: internal 3rdparty internal-Extension-Name: myAppPkg
3rdparty-Extension-Name: my3rdPartyPkg internal-Specification-Version: 2.0
3rdparty-Implementation-Version: 8.1GA
By default, when WebLogic Server deploys an application or module and it cannot resolve a reference in the applications manifest file to an optional package, WebLogic
Server prints a warning, but continues with the deployment anyway. You can change this behavior by setting the system property
weblogic.application.RequireOptionalPackages to true when you start WebLogic Server, either at the command line or in the command script file from which
you start the server. Setting this system property to true means that WebLogic Server does not attempt to deploy an application or module if it cannot resolve an optional
package reference in its manifest file.
9.5 Using weblogic.appmerge to Merge Libraries
