Jar dependency - app server path - add it to the app war itself
We have a Weblogic 10.3.6 installation. The application running on it needs the following can
com.oracle.ws.http_client_1.3.0.0.jar
The above jar is in the server package Oracle \ Middleware \ modules \ com.oracle.ws.http_client_1.3.0.0.jar
What's the correct approach? If this jar (appears to be a system library written by Oracle not found on the mvnrepository site) is added to the server classpath or should I add it to the application archive (war)? Thank.
Update: also the above banner comes bundled with Weblogic (not added to the classpath by default) and was not found in the maven public repo. So this is not meant to be added directly to the application?
source to share
-
If the box is part of the app server environment / build, I would not add it to the war / ear file. It must be accessible through all DIT / UAT / PROD envs (envs must be prod compatible). Also, when serever app patches are applied or the server is updated, we will use the latest jar.
-
In other cases (external) it would be better to package it in war to avoid problems when switching from env to env.
source to share
The best place to put JAR files and other dependencies is a package in a WAR, not a system
classpath
. By doing this you have the following benefits.
- The WAR file is self-contained and reliable without any dependency on it
container
. - The same WAR file without packaging changes can be deployed to DEV, IT, QA, Demo, Test, Production, blah, blah, or any environment today.
- No problem between
system
andwebapp
classloaders
.
There may be debate, as packaging everything in the WAR file may end up increasing the WAR file size . But it is really frustrating when there is a funny production bug, of which there is no middle of the night just because you missed the update http_client_1.3.0.0.jar
to
http_client_1.4.x.y.jar
and others point out directly that the same WAR file worked fine in the test environment.
In my experience, I find the consistency of the WAR file to be an important aspect. And therefore, suggest that you package every required JAR file in a WAR until the JAR is implicitly provided by the container.
- Disk space cost per GB = $ 1
- Efforts to resolve inconsistency issue = $ 50
- A Midnight Sleep Vacation to Solve a Crazy Problem = Priceless
:)
source to share
It depends. When you insert a dependency inside the default classpath loaded by a classloader, then, for example, all enums and singles are initialized by that default classloader. Depending on the server configuration, all applications will exchange these instances, or they can create their own instances on their own.
Also, when you add a classpath dependency, it becomes available to all applications on the server, whether they need it or not.
If you only have one app, it won't be affected. If there are more, it would be safer to add the JAR to your application unless you explicitly want this library (and this particular version) to be globally available on the server to use all WAR deployed.
EDIT:
Obviously, you can rest assured that each application will have its own instances of enums and singlets, as described here . So your only problem with the classpath method will be that different applications will require different versions of the same library.
source to share