Creating Shared Java EE Libraries and Optional Packages 9-17
the referencing application have higher precedence over modules in the referenced applications. If a client invokes the myOtherEJB EJB, then WebLogic Server invokes
the one in myLibA, because the library is referenced first in the weblogic-application.xml file of myApp, and thus has precedence over the EJB
with the same name in the myLibB application.
9.12 Best Practices for Using Shared Java EE Libraries
Keep in mind these best practices when developing shared Java EE libraries and optional packages:
■
Use shared Java EE Libraries when you want to share one or more Java EE modules EJBs, Web applications, Enterprise applications, or plain Java classes
with multiple Enterprise applications.
■
If you need to deploy a standalone Java EE module, such as an EJB JAR file, as a shared Java EE library, package the module within an Enterprise application.
Doing so avoids potential URI conflicts, because the library URI of a standalone module is derived from the deployment name.
■
If you choose to deploy a shared Java EE library as a standalone Java EE module, always specify a known deployment name during deployment and use that name
as the URI in referencing applications.
■
Use optional packages when multiple Java EE archive files need to share a set of Java classes.
■
If you have a set of classes that must be available to applications in an entire domain, and you do not frequently update those classes for example, if you need
to share 3rd party classes in a domain, use the domain lib subdirectory rather than using shared Java EE libraries or optional packages. Classes in the lib
subdirectory are made available within a separate system level classloader to all J2EE applications running on WebLogic Server instances in the domain.
■
Always specify a specification version and implementation version, even if you do not intend to enforce version requirements with dependent applications.
Specifying versions for shared Java EE libraries enables you to deploy multiple versions of the shared files for testing.
■
Always specify an Extension-Name value for each shared Java EE library. If you do not specify an extension name, one is derived from the deployment name of the
library. Default deployment names are different for archive and exploded archive deployments, and they can be set to arbitrary values in the deployment command
■
When developing a Web application for deployment as a shared Java EE library, use a unique context root. If the context root conflicts with the context root in a
dependent Java EE application, use the context-root element in the EARs weblogic-application.xml deployment descriptor to override the librarys
context root.
■
Package shared Java EE libraries as archive files for delivery to Administrators or deployers in your organization. Deploy libraries from exploded archive directories
during development to allow for easy updates and repeated redeployments.
■
Deploy shared Java EE libraries to all WebLogic Server instances on which you want to deploy dependent applications and archives. If a library is not registered
with a server instance on which you want to deploy a referencing application, deployment of the referencing application fails.
9-18 Developing Applications for Oracle WebLogic Server
10
Programming Application Life Cycle Events 10-1
10
Programming Application Life Cycle Events
The following sections describe how to create applications that respond to WebLogic Server application life cycle events:
■
Section 10.1, Understanding Application Life Cycle Events
