In the previous sections of this chapter, we discussed the new Java EE 6, but how do we get it to work under our new WebLogic 12c Server?
In WebLogic Server 12c, you can make use of the shared Java EE library feature in WebLogic Server which provides an easy way to share one or more different types of modules among multiple enterprise applications. A shared library is a single module or collection of modules that is registered with the Java EE application container upon deployment. A shared library could be:
You should package a shared library into your built and compiled archive file (EAR, JAR, or WAR). However, you may also choose to deploy shared as exploded archive directories to facilitate repeated updates and redeployments (for development purposes).
After the library has been registered, you can deploy applications which refer to the library. Each referencing application receives a reference to the required library on deployment, and can use the modules that make up the library as if they were packaged as part of the referencing application itself. The library classes are added to the classpath of the referencing application, and the referencing application's deployment descriptors are merged (in memory) with those of the modules that make up the shared Java EE library.
There are some things to keep in mind while using shared libraries. If you develop shared Java EE libraries and optional packages, follow these rules:
- You should use shared libraries to share them amongst one or more Java EE modules (EJBs, web applications, enterprise applications, or Java classes) with multiple 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. This avoids potential URI conflicts, because the library URI of a standalone module is derived from the deployment name.
- Optional packages are used 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 which do not need to be updated very frequently, then use the domain
/libsubdirectory instead of using the shared Java EE libraries or optional packages. Classes in the/libsubdirectory are made available (within a separate system-level classloader) to all Java EE applications running on WebLogic Server. - Always use versioning, even if you do not intend to enforce version requirements with dependent applications. Specifying versions for shared libraries enables to deploy multiple versions of the shared files for testing.
- It is better to specify an Extension-Name value for each particular shared library. If you don't, one will be taken 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.
- For web applications, always use a unique context root when you develop it as a shared Java EE library. If the context root conflicts with the context root in a dependent Java EE application, use the
context-rootelement in the EAR'sweblogic-application.xmldeployment descriptor to override the library's context root. - For your deployers and admins, create a package of the shared libraries, package them into an archive file and deploy libraries from exploded archive directories during development to allow for easy updates and repeated redeployments.
- Deploy and target shared Java EE libraries to all WebLogic Server instances on which you want to deploy dependent applications and archives, otherwise the application fails.
One of the nice things about the new WebLogic 12c is that you don't have to recompile or rebuild its previous application classes or libraries.
With one exception, upgrading to WebLogic Server 12c Release 1 (12.1.1) does not require you to recompile applications in order to create new generated classes.
The only exception here is the EJBGen utility. The current version of the EJBGen utility recognizes only JDK 5.0 or later metadata annotation-style EJBGen tags and not the old Javadoc-style tags. This means that source files that use the Javadoc-style tags must be upgraded to use the equivalent annotation, and then recompiled using the updated version of EJBGen.
So how does Java EE 6 fit in to Cloud Technology?
The WebLogic 12c has been utilized for Oracle technical solutions for the cloud, Engineered Systems or better called Exalogic. Applications running in the cloud with the Java EE S6 specifications have:
- Tighter requirements for resource and state management
- Better isolation between applications for controlling lifecycling in the Java Virtual Machine
- Standard APIs for NoSQL Databases, Caching, and so on
- Support for HTML5
- Common management and monitoring interfaces
- Better packaging