Application Libraries - Part III Deployment and Versioning

(Migrated from Rob Woollen's blog on dev2dev with his permission. This entry was originally posted on August 22, 2005 02:40 PM)

Library Deployment / Undeployment

Application libraries use the same deployment and distribution machinery as "regular" applications so users are not forced to learn a new set of commands. A library is deployed with either the WebLogic Administration Console, the weblogic.Deployer command-line, the wldeploy ant task, WLST scripting, or the programmatic deployment APIs. Library deployment distributes the files to the target servers and registers itself with the target server's library manager. When an application references a library, the library manager is consulted to ensure the library exists and the correct version is "linked" with the application.

After library deployment, one or more applications may be deployed which reference the library. As was discussed earlier in this series, each referencing application imports its own library copy. The purpose of libraries is to change the packaging of J2EE applications not their semantics.

Libraries may also be undeployed to unregister them and remove their files. Undeploying the library is only possible if there are no deployed applications current referencing it. An attempt to undeploy a library which is still being used will be refused with an error message instructing the user which applications are still referencing it.

Versioning Use Cases

product documentation
provides a lot of background on libraries and their versoning support. Instead of duplicating that effort here, I thought I'd cover a few common use cases, and how they can be solved with library versioning along with some examples.

A library may include a standard java manifest file which supplies version information. The
product documentation
covers this topic in depth, but the main idea is each manifest may optionally include a specification-version and an implementation-version.

An application includes a library with an entry in its weblogic-application.xml. The entry may optionally specify a specification-version and implementation-version. If a version is not specified, the server defaults to using the latest deployed library version. When a version is specified it indicates the app wants that version or later. The exact-match flag indicates that a later version is not acceptable and only the exact specified version will be used.

The rules are relatively straightforward, but some quick examples will probably help.


Deployed Libraries

Assume the server currently has 2 versions of the DAO-LIB library deployed:

Name Specification-Version Implementation-Version Abbreviation
DAO-LIB 2 3 2/3
DAO-LIB 3 1 3/1

Note for convenvience, I will abbreviate spec-version of x and impl-version of y as (x/y).

Application library References

Now consider which library is used when applications are deployed with the following DAO-LIB references:

Name Specification-Version Implementation-Version Exact-Match Which library is used? Why?
DAO-LIB Not specified Not specified Not specified 3/1 No spec-version was specified so latest is used.
DAO-LIB 2 Not specified Not specified 3/1 App is requesting spec-version >=2. 3/1 is the highest >= 2
DAO-LIB 2 Not specified True 2/3 Exact-Match requires only library with spec-version 2 to match
DAO-LIB 4 Not specified Not specified None Deployment fails since no app has spec-version >= 4
DAO-LIB 2 4 Not specified None Deployment fails since no app has impl-version >= 4

Version Recommendations

It is good practice for each library to include a specification-version and implementation-version. Both versions should be decimals or dewey decimals (eg major.minor.patch) rather than arbitray strings (this makes them comparable.) The specification-version should change when any of the interfaces or conventions change incompatability (basically anytime a referencing application would have to change or recompile.) The implementation-version can be a build number.

Most referencing applications should specify a specification-version and exact-match=true but not specify an implementation-version. This allows the admin to use a newer library build with the latest bug fixes without updating all the referencing application EARs.

Use Cases

  1. Integrating Library Bug Fixes

  2. In this scenario the admin receives a new, compatible version of the library with some bug fixes. The library would have changed its implementation-version but not its specification-version. The new library build can be deployed to the server. The application should have specified only a spec-version in its descriptor and when it is redeployed it will automatically pick up the latest library with the bug fixes.

  3. Multiple applications using different library versions

  4. In this scenario there are multiple, incompatabile versions of the library being used by different applications. This might occur if an application has not been tested, certified, or updated with the latest library, but another application requires new library functionality. This can be accomplished by deploying the incompatabile libraries with different specification-versions. The referencing applications should specify their required version and set exact-match. This ensures each application will in parallel find their appropriate library version.

  5. Zero downtime upgrade of library applications

  6. Application upgrade without downtime is worthy of its own future blog entry. The product documentation covers the background information on this topic. In the library scenario, the first step would be to deploy the new library version. Since libraries only distribute code and register themselves, this won't interrupt any existing applications. Next, the new application can be deployed alongside the existing application version. If the library has changed as well, the updated application can specify exactly what version of the library it requires.

I hope these blog entries have shown you the flexiblity that libraries now offer in WLS 9. There are many more innovative features in WLS 9 that I'll try to cover in the next few weeks.


Thanks -- this is really useful to know esp if one is working with WL and deployment of apps onto WL. great stuff. :)

Posted by Siphiwe on June 24, 2010 at 08:22 PM PDT #

ngviwe hvbwerv hvnVNIPRQ jbm3rqiof jvn43o bn5r3eo5hjrn nvbr0ile bniwprsin

Posted by Stewart Engblom on October 25, 2010 at 10:15 AM PDT #

Hi, i must say fantastic website you have, i stumbled across it in Yahoo. Does you get much traffic?

Posted by Jocuri on November 30, 2010 at 02:32 PM PST #

The blog was how do i say it... relevant, finally something that helped me. Thanks:)

Posted by Rene Hambright on February 03, 2011 at 10:37 AM PST #

Blog is good!:) Perhaps you learn me blog myself??

Posted by Yer Lash on February 03, 2011 at 03:52 PM PST #

I kinda like this blog. For some time, I've been making an attempt to create one one thing like this as properly, however I'm not computer gifted on easy methods to do it.I kinda like this blog. For some time, I've been attempting to create one one thing like this as well, however I'm not laptop gifted on the right way to do it.

Posted by liability insurance on March 04, 2011 at 06:03 AM PST #

I am constantly thought about this, appreciate it for putting up.

Posted by Sol Mcwade on April 27, 2011 at 04:57 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

The official blog for Oracle WebLogic Server fans and followers!

Stay Connected


« June 2016