Configuring context root for web application libraries
By Aseembajaj-Oracle on Dec 22, 2008
There are many ways to configure context root for web applications and modules in WebLogic Server. There are rules around context root configuration of shared web application libraries too. This post intends to put all these configuration settings together. To read more about shared Java EE libraries supported by WebLogic Server, please refer to the documentation.
To begin with, let's go through context root configuration in non-library scenarios.
1. When a standalone web application is deployed, the context root is the file name sans the .war suffix. This can be overridden by the use of <context-root> setting in weblogic.xml. In such cases the configured value is used.
2. When an enterprise application is deployed without application.xml, enclosed web modules are deployed with context root of module URI sans the .war suffix. This scenario only works with release 10.0 (Java EE 5) onwards. On earlier edition, such an application would not deploy.
3. When an enterprise application is deployed with application.xml no module scanning is performed. The declared web modules are deployed with the value from the declared <context-root> element in application.xml. This element is mandatory according to schema for application.xml. This configuration would override any <context-root> declaration in weblogic.xml of the module.
WebLogic Server supports the use of shared web application libraries that can be referred to from any of the following:
1. Enterprise applications or shared enterprise application libraries
2. Web applications, web modules or shared web application libraries
The meaning of such a reference is different in the two cases. The former implies that the referred shared web application library be added as a module to the enterprise application artifact. In doing so, context-root of this web module is set to the library file name sans the .war suffix. Therefore, any <context-root> declaration in weblogic.xml is ignored. This behavior can be overridden:
1. While referring to a shared web application library using <library-ref> element in weblogic-application.xml, an optional element <context-root> may be used. This declaration ensures that the context root of the library web module is set to the configured value.
2. <context-root> setting in <library-ref> may be further overridden by the use of <library-context-root-override> element in weblogic-application.xml. This overriding configuration element has been added to cater to 3rd party library scenarios. Say customer app A.ear refers to vendor library V.ear which in turn refers to another vendor library V.war. Since customer has no control over <library-ref> declaration in V.ear, <library-context-root-override> gives her a way to override context root for V.war.
When a web application, module or shared library refers to a shared web application library, the latter is merged into the former. In such cases, <context-root> declaration in weblogic.xml of the library is ignored. <context-root> declaration in <library-ref> of weblogic.xml is also ignored.
After I sent out the compilation of these rules to a colleague of mine, Konstantin Komissarchik, he wrote back requesting a few clarifications. I though it'll be useful to share his queries and my responses in this post.
Q. Could you confirm that the library name (as specified in manifest or at deployment) is not considered here and that the starting value is always based on library file name?
A. Yes, the name is NOT considered.
Q. What about the exploded web library case? Is that even supported?
A. It is supported and the same rules apply as archived shared web application libraries.
Q. Could you confirm that library-context-root-override is more generic than just the above scenario? Let's assume an EAR referencing libraries that don't reference other libraries. Can library-context-root-override be used instead of context-root element of library-ref when referencing a war library?
A. No. <library-context-root-override> only overrides <context-root> of <library-ref>. It's not good by itself. In your scenario, you'll have to use <context-root> under <library-ref>.
Q. Can library-context-root-override be used when referencing ear library to override context roots of contained web modules?
A. No. In fact there is no such configuration that could be applied to enterprise shared library reference that would override configuration for all modules.
Q. If you have A.ear referencing library B.war, and you have <context-root> specified in <library-ref> element for B.war, can you then override that context root using <library-context-root-override> in the same
weblogic-application.xml file? Or can only override <context-root> declarations from indirect references.
A. Yes, you can apply <library-context-root-override> to a context-root declared in <context-root> declaration of <library-ref> of the same weblogic-application.xml
Q. Are there any nesting limits on how deep of a reference you can override? Say you have A.ear which references library B.ear which references C.ear which references D.war and specifies <context-root>. Can you use <library-context-root-override> element in A.ear to change the context root that D.war is mapped to?
A. There are no nesting limits on libraries. So there is no nesting limit for this override. In this scenario, the use of <library-context-root-override> would work.
Q. Is it possible to use <library-context-root-override> in an EAR library (rather than EAR application)? In the scenario described in #2 above, can <library-context-root-override> be placed in B.ear or C.ear and have the same effect of placing it in A.ear. If the answer to this question is yes, what happens if you want to override again in A.ear? Is that allowed? If yes, are you overriding the override or the original value specified in the <context-root> element.
A. The schema of weblogic-application.xml is the same for enterprise applications and shared enterprise application libraries. So the presence of <library-context-root-override> is allowed in weblogic-application.xml of shared enterprise application libraries. But it is ignored.
(Picture licensed from Athanasius under Creative Commons)