I've experienced a strange error coming out of the Weblogic wldeploy tool recently. It was reporting that a context path used by my shared library is already in use when I was trying to deploy a new web service. This seemed confusing to me - I had two web services that were both referencing the same shared library, the first service would deploy without any issues while the second would fail deployment with the context root error. Shared libraries by their nature are meant to be shared so what was the issue?

This was the kind of error I was seeing...


After a fair amount of research I stumbled upon this article: Configuring context root for web application libraries. This got me thinking.

My environment had my shared library deployed already, as a war file, following a process similar to this article. Lets assume the shared library name was my.shared.lib, both the implementation and specification versions were 1.0, and most importantly the war file name was my_shared_lib.war.

Now the first web service that was deployed was referencing this shared library from its weblogic-application.xml file like this:




Since the library reference is at the application level, the shared library is treated as a module of the application and hence requires its own context root. WebLogic takes the name of the war file sans the .war extension as the default value for the context root. In this case, it was my_shared_lib.

The second web service had the same identical weblogic-application.xml file so WebLogic tried to create the same context path for the shared library imported by that service, causing a name collision.

There are a number of solutions to this:

• Move the library-ref to weblogic.xml file instead.
• Adjust the context root of the imported library.

The first option is fairly simple, just cut and paste between two files.

The second option is achieved by adding a context-root element into library-ref that has a unique value for the context root based on the web service name so that the reference looks something like this (or really just any unique value):


The second web service would then have a different value for the context-root element. Redeploying both services solves the issue.

Both approaches are valid but my preferred one is to reference the library at the module level i.e. in the weblogic.xml file so that the library never gets its own module created inside the application in the first place.

-i