From a performance point of view and memory imprint, there’s absolutely no change : the library will still be loaded in each and every EAR classloader.
But from a packaging point of view, it allows you to reduce significantly the size of your archives, by externalizing the common libraries.
Moreover, when you have to upgrade one of your lib, it’s easier to do, thanks to centralization.
In my case, I’m currently working on a key SOA project on which a huge work had been done on isolating services from a business point of view.
But technically, all the services were packaged in the same EAR, which is a serious problem for the high availability we are supposed to provide.
(in case of a new version, it would lead to an undeployment of the whole archive : production redeployment is not an option since the archive is pretty bulky)
So I had to explode the EAR in several WARs and adopt a strategy for the library sharing.
First of all, whether you'll use the “shared library” or the “optional package” mechanism, your libraries (JARs in our case but can be WAR, RAR …)
must respect a certain definition in their manifests, such as :
This example has been inspired by the example found on sun.com.Extension-Name: fr.mbutton.blog Specification-Vendor: Tengah Consulting Specification-Version: 1.0 Implementation-Vendor-Id: fr.tengah-consulting Implementation-Vendor: Tengah Consulting Implementation-Version: 1.1
Based on my experience, the only lines that really matter are the following :
WebLogic Server will use the extension name to determine the name it will use for the library you’re deploying.Extension-Name: fr.mbutton.blog Specification-Version: 1.0 Implementation-Version: 1.1
If none, then the name of the file itself will be used to qualify deployed archive name, as explained on Oracle documentation.
In my case, I had to list all the libraries used in our application and see whether they were eligible for being deployed as a shared library.
And I realized that lots of libraries you can find on the market are / were not thought to be deployed as optional package / shared libraries.
So far, the only libraries that were clearly designed following this standard are the libs from Apache.
Regarding the specification & implementation versions, you may specify those pieces of information while deploying,
but it is a good practice to have them described in the library manifest.
Moreover as described in the official Oracle documentation, you should be careful while using this modus operandi :
“If both the manifest file and theReferencing Shared Libraries
weblogic.Deployercommand line specify version information, and the values do not match, the deployment fails.
If you initially registered a library without providing a specification or implementation version,
you must undeploy the library before registering a newer version and specifying version string information.
You can register multiple versions of a library or package, but each version must use the same version strings.
For example, you cannot register a library having only a specification version,
and then register a new version of the library having both a specification and an implementation version.”
Now our libraries are correctly defined and deployed the use as shared libraries is really simple.
According to the documentation about the weblogic deployment descriptors (weblogic.xml & weblogic-application.xml), the way to reference a library is the following :
But one major problem is that you cannot reference all the types, just as it is clearly said in the official documentation :<library-ref> <library-name>fr.mbutton.blog</library-name> <specification-version>1.0</specification-version> <implementation-version>1.1</implementation-version> <exact-match>false</exact-match> </library-ref>
“You cannot reference any other type of shared Java EE library (EJB, Enterprise application, or plain JAR file)In other words, it is impossible to reference JAR files in a web application (WAR).
weblogic.xmldeployment descriptor file of a Web Application.”
Hummmm … annoying since it’s exactly what I’m trying to do …
Then my friend & colleague Romain told me about the optional packages.
Referencing Optional Packages
With optional packages, that annoying limitation is no more.
If you followed the pieces of advice regarding the correct deployment of libraries for a use as shared libraries,
that’s perfect because you won’t have anything to change to switch to optional packages.
The only thing that changes is the way you will refer to them.
Using optional packages, you simply have to update the manifest for your WAR such as :
And suppose we have another library :Extension-List: blog blog-Extension-Name: fr.mbutton.blog blog-Specification-Version: 1.0 blog-Implementation-Version: 1.1
This time, the definition in the manifest would be :<library-ref> <library-name>org.springframework</library-name> <specification-version>3.0</specification-version> <implementation-version>3.9beta</implementation-version> <exact-match>false</exact-match> </library-ref>
Once again, I’m not inventing this : you can read it here.Extension-List: blog spring blog-Extension-Name: fr.mbutton.blog spring-Extension-Name: org.springframework blog-Specification-Version: 1.0 spring-Implementation-Version: 3.9beta
Okay here we are, time for a conclusion !
Shared libraries :
- are cool but do not allow all type of referencing (-)
- are WebLogic Server specific (-)
- are XML based (+?)
- are standard … (+)
- … but completely based on manifests : almost worst than Cobol ! (-)
- allow a lot more possibilities (+)
Mots clés Technorati : weblogic server,optional packages,shared libraries,manifest,sharing jar across wars