CODEWITHSUNDEEP
javajakarta-eeweb-applications
chows2603
chows2603

Reputation: 176

If a jar file is required by multiple web applications?

If a jar file is required by multiple web applications then which option will you choose? Keeping it in server classpath or keeping one copy of the jar file for each web application's lib folder?

Upvotes: 5

Views: 737

Answers (3)

Puce
Puce

Reputation: 38142

I would recommend to have a copy for each web application, if the library is not already included in your application server (such as Java EE libraries) and not to change the server classpath for this purpose.

I will make it easier to manage the dependencies of your web applications and their versions.

Upvotes: 0

BalusC
BalusC

Reputation: 1109162

Technically, it depends on what kind of JAR file it is and usually you have only one option.

If it's a Java EE based "web fragment" JAR file, recognizable by having a /META-INF/web-fragment.xml file, and/or a /META-INF/faces-config.xml, and/or a /META-INF/*.tld file, and/or a /META-INF/resources folder containing web content files (JSP/CSS/JS/etc), then it definitely belongs in WAR's /WEB-INF/lib. Otherwise annotated/registered web fragment artifacts (modular servlets, filters, listeners, tags, components, beans, etc) won't be auto scanned, discovered and installed, and/or web fragment resources (shared JSP/Facelets/CSS/JS/image files) can't be included in webapp.

Or if it represents an implementation of a Java EE API, such as JSF, JSTL, JAX-RS, etc, then it can (should) go in server's /lib, but then you must make sure that you replace any existing/older implementation, otherwise you may run into classloading trouble caused by duplicate different versioned libraries in runtime classpath (recognizable by class/method/field related exceptions such as NoSuchMethodError, LinkageError, etc). If you include it in WAR anyway, then you need to make sure that you instruct the server or the API in question to use WAR-bundled implementation instead of the server-bundled one.

Else it's most likely a "plain vanilla" Java SE based library, such as Apache Commons and friends. Such a library can safely go in server's /lib and be shared among all webapps. This is at least required for JDBC drivers and smiliar JARs having a service loader which auto-loads stuff into memory during JVM startup, recognizable by a /META-INF/services folder targeted on a Java SE based API. Otherwise memory leak risks may occur during hotdeployments when such a library is placed in webapp's /WEB-INF/lib, because it can't signal a Java EE undeploy and blindly auto-loads stuff once again while the JVM hasn't shutdown.

See also:

Upvotes: 3

user4114581
user4114581

Reputation:

If you have most of your web applications using same library, then you most likely need to keep it in server classpath. Each web application loaded by isolated (new) classloader - so during runtime such classloader will load and define classes from library and store in perm gen. This can cause unnecessary memory allocation. The only escape is to register library on the server and (not necessarily because classloader follows delegation model) package war excluding this library.

But if there're only few of them, keep it in lib under WEB-INF. If dependent application will be undeployed to release resources - library classes will still be loaded and useless

Apache Tomcat classloaders ref:
https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html

Upvotes: 0

Related Questions