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.