Creating Shared Java EE Libraries and Optional Packages 9-3
9.1.2 Library Directories
The Java EE platform provides several mechanisms for applications to use optional packages and shared libraries. Libraries can be bundled with an application or may be
installed separately for use by any application. An EAR file may contain a directory that contains libraries packaged in JAR files. The library-directory element of
the EAR files deployment descriptor contains the name of this directory. If a library-directory element isnt specified, or if the EAR file does not contain a
deployment descriptor, the directory named lib is used. An empty library-directory element may be used to specify that there is no library
directory. All files in this directory but not in subdirectories with a .jar extension must be made available to all components packaged in the EAR file, including
application clients. These libraries may reference other libraries, either bundled with the application or installed separately.
This feature is similar to the APP-INFlib feature supported in WebLogic Server. If both APP-INFlib and library-directory exist, then the jars in the
library-directory would take precedence; that is, they would be placed before the APP-INFlib jar files in the classpath. For more information on APP-INFlib,
see
Section 8.3, Resolving Class References Between Modules and Applications and
Section 3.4, Organizing Shared Classes in a Split Development Directory .
9.1.3 Versioning Support for Libraries
WebLogic Server supports versioning of shared Java EE libraries, so that referencing applications can specify a required minimum version of the library to use, or an exact,
required version. WebLogic Server supports two levels of versioning for shared Java EE libraries, as described in the Optional Package Versioning document at
http:java.sun.comj2se1.4.2docsguideextensionsversioning.html:
■
Specification Version—Identifies the version number of the specification for example, the Java EE specification version to which a shared Java EE library or
optional package conforms.
■
Implementation Version—Identifies the version number of the actual code implementation for the library or package. For example, this would correspond to
the actual revision number or release number of your code. Note that you must also provide a specification version in order to specify an implementation version.
As a best practice, Oracle recommends that you always include version information a specification version, or both an implementation and specification version when
creating shared Java EE libraries. Creating and updating version information as you develop shared components allows you to deploy multiple versions of those
components simultaneously for testing. If you include no version information, or fail to increment the version string, then you must undeploy existing libraries before you
can deploy the newer one. See
Section 9.7, Deploying Shared Java EE Libraries and Dependent Applications
. Versioning information in the referencing application determines the library and
package version requirements for that application. Different applications can require different versions of a given library or package. For example, a production application
may require a specific version of a library, because only that library has been fully approved for production use. An internal application may be configured to always use
Note: Oracle documentation and WebLogic Server utilities use the term
library to refer to both Java EE libraries and optional packages. Optional packages are called out only when necessary.
9-4 Developing Applications for Oracle WebLogic Server
a minimum version of the same library. Applications that require no specific version can be configured to use the latest version of the library.
Section 9.3, Referencing Shared Java EE Libraries in an Enterprise Application
.
9.1.4 Shared Java EE Libraries and Optional Packages Compared
Kategori