Application Libraries - Part II Semantics

(Migrated from Rob Woollen's blog on dev2dev with his permission. This entry was originally posted on August 08, 2005 11:29 AM)

Designing large software features like application libraries is always an interesting challenge. While it wasn't initially a stated goal, in retrospect the design was heavily influenced by a desire to minimize the implementation work. I'm certainly not trying to imply the development team was lazy, but minimizing new concepts became the best means to achieve our main design goals:

  1. Address customer use cases, specifically separately packaged code libraries potentially shared between many applications and versioned independently.

  2. Make it easily possible to port library-based applications to earlier WLS releases or other J2EE servers.

  3. Ensure libraries are easily understood and require limited change to existing applications.

  4. Provide equivalent deployment, versioning, and management functionality as non-library applications.

I'd really like to emphasize the second point here. While libraries are an innovative feature only in our application server, they aren't meant to lock developers into 9.0. The design strives to make it easy and natural to port library-based applications to older WLS releases or other J2EE servers which don't support this concept.

With those goals in mind, the design that evolved was simply that library applications have the same semantics as if they were deployed together as a single EAR file. Internally the server runs through a series of steps as applications are deployed on the target server. During an early stage in deployment, it establishes which modules are in an application and instantiates containers for each. These might be ejb or web modules declared directly in the
application.xml, or they may be imported from a library. The only real difference is the path on disk to the module.

The vital piece to understand is that libraries only change the path where classes and resources are loaded. After the container is created, all semantic behavior is exactly as if everything was within a single EAR file. The classloading, management, console pages etc are all the same. Libraries are merely a packaging concept.

Libraries can be either java classes, a single component (eg a war or ejb-jar), or an EAR file with 1 or more components. In the java class case, the server just adds the jar file to the application's classloader. The single component case is essentially adding a new module entry to the application.xml with a different relative path to the ejb-jar or webapp.

EAR libraries are a slightly more complicated case since the library has its own application.xml and weblogic-application.xml. The server handles this by merging the library's application.xml with the application.xml in the application. The merge is relatively straightforward, but it should be noted that the application's descriptor takes precedence on any conflict. For instance, if you had the same ejb module (same uri) in both the library and the application, the application's version would be used. (I included this information for completeness, but I would recommend that applications not override library modules. If this is necessary, I would suggest repackaging the library as needed.)

Another main design issue was the semantics when multiple applications reference the same library. One option is to have a single library instance shared by all referencing applications. This has some classloader advantages, but it makes redeploying the applications and libraries significantly more complicated. The design instead favored the simpler and more flexible approach where each application included its own library component copy. This approach's advantages may become clearer in the next blog entry which discusses versioning, upgrades, and how to undeploy a library.

WLS 9 includes a tool weblogic.appmerge (run java weblogic.appmerge to see usage) which given an application and 1 or more libraries produces a single, merged EAR file. The tool's merge process shares the same code with the server, but instead of merging data structures in memory, it writes the output to disk. The appmerge tool can be used to debug or better understand how libraries work, but it also allows porting to other servers or older WLS releases.

I hope this blog entry provided further insight into Application Libraries. In my next entry, I'll cover how libraries are versioned, deployed/undeployed, and zero downtime library upgrades. Please post a comment if there's anything that is unclear or suggestions on further topics.


i think this article is not good because the information of semantics is really decrease for me........

Posted by risqi on June 22, 2009 at 03:43 PM PDT #

I am using WebLogic 10.3. I have deployed a EJB Shared Library as an EAR File. The intention is to make multiple applications(EAR files) refer the same library(as you have stated in your blog above) . So far I am able to deploy only one application (EAR file) which refers this library in its "weblogic-application.xml" file and deploying another application gives me a "JNDI Name already in use" error. From your blog.. "The design instead favored the simpler and more flexible approach where each application included its own library component copy" What happens when I include a reference to a library in application's "weblogic-application.xml" file ?? Does it try to deploy the library ?? If not where do you think I am going wrong ?

Posted by Jatin Parmar on September 08, 2009 at 02:30 AM PDT #

Hi Jatin, You probably have remote interfaces for your EJBs. In that case, the second deployment is bound to fail because it'll try and deploy a new instance of your EJB and would try and bind it to the global JNDI tree at the same location where an earlier instance has been bound. If you do not need the remote interfaces, you could consider removing them. Alternatively, you could use deployment plan to override JNDI name for your EJB during the second deployment. Quote: "I have deployed a EJB Shared Library as an EAR File. The intention is to make multiple applications(EAR files) refer the same library": On a separate note, you don't need to package your EJB module in an enterprise application library. You could simply deploy your EJB module (.jar) as a library and refer to it from your enterprise applications.

Posted by Aseem Bajaj on September 15, 2009 at 07:19 AM PDT #

We are trying to separate the library from the mail application. For a small unit of example, we have 4 libray jar files. And the main application is packaged inside an EAR file. We want to generate an EAR containing those four library files and deploy that EAR as a library. And then the main application.ear as an application which will refer to the library with the libraryref in its weblogic-application.xml file. Here, we are stuck in the following points: 1. when we deploy a single jar as a library and deploy the application ear, it works and the application gets deployed, but when we create a library.jar containg many library jars and then do the deployment it fails as the application is not able to find the jars within the LIBRARY.jar 2. So, we thought of packaging those libraries as EAR, here the problem is if we use ajr utility or RSA, it needs an application.xml that may have issues of precedence with the application.xml of the application ear. Moreover, we need to mention a module there in the application.xml file 3.Hence I tried to merge those jar files using weblogic.appmerge utility as mentuioned in I went to /bea/wlserver_10.3/common/bin and ran the to set the env as . ./ and then used that java weblogic.appmerge -output ManyLibraries.ear -library library1.ear library2.ear but again it throws error like,Exception in thread "Main Thread" java.lang.NoClassDefFoundError: weblogic/appmerge How can I use this utility, do I need to download anything extra? 4. Our Application.ear also consists of many jar files and they have inner dependency with other many jars that are mentioned in the classpath of their manifest. HOW CAN I PACKAGE AN EAR CONSISTING OF MULTIPLE LIBRARY JARS?

Posted by subh on December 16, 2009 at 02:49 PM PST #

Nice post , uno dei migliori blog su stringhe Ho letto .

Posted by Asley Higginbotham on March 25, 2010 at 08:17 AM PDT #

Really good post, this will help me a lot to get comments in my blog. Now I know why people do not comment in my blog.

Posted by Smith Taylor on April 27, 2010 at 11:32 AM PDT #

Sorry for the out of place comment admin, I was unable to find an email address to email you at and assumed you would read this befor accepting the comment anyway. I just wanted to share this really cool traffic trick for your blog because I think you will benifit greatly from it. I was able to go from $3.23/day to $83.44/day (I know the site says $300+ but oh well lol maybe im not doing it right, cant complain). I think you will get the same results easy, check it out:

Posted by Read then delete on October 26, 2010 at 06:30 AM PDT #

Daaaammmm howd you get that layout yo! its FREESSHH!!

Posted by Backlinks on January 26, 2011 at 02:00 PM PST #

Between me and my husband we've owned more MP3 players over the years than I can count, including Sansas, iRivers, iPods (classic & touch), the Ibiza Rhapsody, etc. But, the last few years I've settled down to one line of players. Why? Because I was happy to discover how well-designed and fun to use the underappreciated (and widely mocked) Zunes are.

Posted by Amanda on January 31, 2011 at 10:25 PM PST #

The only place you'll find success before work is in the dictionary

Posted by Belinda on January 31, 2011 at 10:39 PM PST #

Unquestionably believe that which you stated. Your favorite reason appeared to be on the net the easiest thing to be aware of. I say to you, I definitely get annoyed while people think about worries that they plainly do not know about. You managed to hit the nail upon the top and defined out the whole thing without having side effect , people could take a signal. Will likely be back to get more. Thanks

Posted by posicionamiento google on February 03, 2011 at 06:35 AM PST #

I admit, I have not been on this webpage in a long time... however it was another joy to see It is such an important topic and ignored by so many, even professionals. I thank you to help making people more aware of possible issues.Great stuff as usual.

Posted by Clomiphene Clomid on February 26, 2011 at 08:53 AM PST #

You got numerous positive points there. I made a search on the issue and found nearly all peoples will agree with your blog.

Posted by Tegretol 200 on March 06, 2011 at 10:33 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

The official blog for Oracle WebLogic Server fans and followers!

Stay Connected


« July 2016