I have two applications deployed on a Tomcat server (v7) , both the applications use same shared library. I wanted to reduce the permgen memory foot print of these apps on JVM so I decided to take the common shared library out of the individual wars and put it in the tomcat library folder.
However this experiment backfired as the ClassLoader is per application context even though I moved the libraries to tomcat lib, shared library is getting loaded into the context of both the apps, worse it is getting loaded into the context of other apps that do not use this shared library.
Is there a way to load the library only once across the contexts in the web server?
I understand the risks of thread safety and security, those risks are mitigated in my case.
Classes from jars in the Tomcat lib directory get their own class loader which is shared amongst all deployed applications.
As you have noted each individual application also has it's own class loader.
At this point it's important to understand where Tomcat finds classes for each application. To paraphrase Apache Tomcat Class Loader HOW-TO, application classes are located in the following order:
JVM bootstrap classes
System classes
/WEB-INF/classes of the application
/WEB-INF/lib/*.jar classes
Common class loader (being jars in the "Tomcat lib" directory)
Items 1,2 & 5 above are separate class loaders with their own repository. Items 3 & 4 are a single class loader, but there is a separate one for each web-app.
Therefore, if you have copied your library jar into the Tomcat lib directory, and not removed it from your web-app then you will still be loading and using the jar in your web-app. Double check the deployment to ensure that the library jar is in fact no longer present in the WEB-INF/lib directory of each app.
Related
I am currently facing an interesting problem where our application fails to start up on 3/4 nodes due to classloading issues.
The problem seems to be that WAS is loading b.jar before a.jar. After troubleshooting more, I found that all of the nodes load the jars in different orders (via Classpath viewer in console) and the working node may have just been a fluke.
How does WebSphere determine the classloading order within an installed applications WEB-INF/lib folder?
Order of loading jars is undefined in websphere. To solve your problem I can suggest you to use one of the below option.
Use manifest classpath settings by mentioning the jar names in a order like how you want them to be loaded.
OR
You can extract the classes from a.jar and put it in the WEB-INF/classes directory. Then remove a.jar from the lib folder. Because classes directory will be loaded before lib directory.
There are 2 ways you can configure the classloader in Websphere, PARENT_FIRST (default) or PARENT_LAST. Classloaders in Websphere are hierarchical, you can think of it as a tree where you have:
Java class loader -> ext class loader -> App module class loader -> web module class loader
PARENT_FIRST will load classes from the "top down" starting with the Java class loaders, whereas PARENT_LAST will load the classes from the "bottom up" starting with the web module class loader. If you are using open source libraries that conflict with WAS-shipped libraries, I would suggest that you use PARENT_LAST.
Take a look at these resources for more info:
http://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/crun_classload.html
http://www.ibm.com/support/knowledgecenter/SSAW57_8.0.0/com.ibm.websphere.nd.doc/info/ae/ae/urun_rclassloader_inst.html
I am trying to add some dependencies jar files. But these files when put in lib/endorsed or in WEB_INF/lib.jar results in startup error for jboss instances. I suppose this is happening because flat classloader structure of JBoss. If somebody has implemented the classloader settings in jboss-web.xml
<class-loading>
<loader-repository>com.example:archive=unique-archive-name</loader-repository>
</class-loading>
Can somebody give me a real life example ?
Also where should I place these jar files - lib/endorsed of jboss, or lib folder in deploy folder or in WEB_INF/lib
Duffymo's directive on not putting jars in endorsed is ignored at your peril.
In some additional detail:
Placing libraries in your WEB-INF/lib is a best practice for portability and consistency as it adheres to a standard provision for creating self-sufficient and distributable web archives, but you need to pay close attention to the class-loading declaration you're putting in your jboss-web.xml.
Assume a simple scenario without the class-loading declaration and a fictional example.jar:
If you place example.jar in WEB-INF/lib and it does not also exist in jboss//lib, then example.jar will only be visible to that specific WAR.
If you place example.jar in WEB-INF/lib and it does also exist in jboss//lib, the instance in WEB-INF/lib will essentially be ignored and the WAR will use the JBoss server instance's unified class loader to load the example classes from jboss//lib/example.jar. (The same would apply to any other WARs or EARs in the same server instance, assuming no class-loading overrides.)
The class-loading declaration is necessary in cases (such as) where you have two different versions of example.jar:
- jboss//lib: example1.0.jar
- WEB-INF/lib: example2.0.jar
In this case, JBoss will create a unique and isolated classloader for your WAR which will avoid jboss//lib/example1.0.jar in favour of WEB-INF/lib/example2.0.jar in the context of your WAR.
In summary, if you're only running one WAR in the jboss server instance and/or you have no conflicting JAR issues, ditch the class-loading declaration and put your JARs in jboss//lib. It makes the WAR file more lightweight, overall deployment may be simpler and you will not consume additional memory with extra class versions during hot-deploys.
They belong in the WEB-INF/lib directory of your WAR file. Don't put things in the endorsed folder.
under a Java Webapp,
I want to set /WEB-INF/lib to D:/somepath/lib
and /WEB-INF/classes to E:/somepath/classes
and web.xml to F:/somepath/config.xml
how to config these under tomcat or jetty to change the convention?
The specification (Java™ Servlet Specification Version 2.3) only mentions standard folders:
The web application classloader must load classes from the WEB-INF/classes
directory first, and then from library JARs in the WEB-INF/lib directory.
With Tomcat or Jetty you cannot do it with "out-of-box" provided functionality:
Tomcat:
WebappX — A class loader is created for each web application that is deployed in a single Tomcat instance. All unpacked classes and resources in the /WEB-INF/classes directory of your web application, plus classes and resources in JAR files under the /WEB-INF/lib directory of your web application, are made visible to this web application, but not to other ones.
Jetty:
The normal configuration is for each web context (web application or war file) is given it's own classloader, which has the system classloader as it's parent. Such a classloader hierarchy is normal in Java, however the servlet specification complicates the hierarchy by requiring that:
Classes contained within WEB-INF/lib or WEB-INF/classes have priority over classes on the parent class loader. This is the opposite of the normal behaviour of a java 2 class loader.
However, you can:
Add extra classpaths to Jetty
Add directory to Tomcat classpath
Cheers
On a Unix system you could do this manually by setting up soft links from the expected places to the locations on the other disks.
Both application servers you mention are open source, so you could write your own version of them. I guess the part that implements the classloader for a web app is what you would have to change.
But if you must engage in such shenanigans, you should suspect that you have made a wrong decision earlier. I can think of no good reason to do what you want to do.
Is there a standard way (i.e. defined by some Java/J2EE/etc. spec) to provide a custom class loader to a Java Servlet Container which should be used to load a WAR file?
On a new project we are extending a large commercial Java software package (Foo) with web services which requires some flexibility of deployment (as separate services, etc). In particular, we want to avoid the necessity to include in each WAR file all of the Foo software dependency Jar files as they are numerous, large, and will be changing with patch/bugfix releases as we develop. Similarly, it is highly undesirable to have to copy all of the dependencies into each Servlet container's "lib" directory.
Ideally, I would like to tell the Java application server that these WAR files must be loaded using a custom class loader which I will provide which automatically includes the Foo software dependency Jars. Something like this (in Java-pseudocode):
public class MyWarFileClassLoader extends ClassLoader {
protected URLClassLoader urlcl;
public MyWarFileClassLoader(File warFile) {
File installDir = System.getEnv("FOO_HOME");
List<File> fooEntries = new File(installDir, "jars").listFiles("*.jar");
fooEntries.add(new File(installDir, "resources"));
fooEntries.add(warFile);
this.urlcl = new URLClassLoader(fooEntries);
}
public Class<?> findClass(String name) {
return this.urlcl.findClass(name);
}
}
If there is no standard way to do this, is there a straightforward way to achieve the same goal for several WAR files, regardless of the target Servlet Container?
[Edit]
To put it another way: is there a common pattern for allowing WAR files to manage their own dependencies at runtime instead of relying on the Servlet Container configuration? I could, of course, have the WAR file manifest include a Class-Path attribute but then the entries are still "hardcoded" at build time rather than detected automatically at runtime.
There is no standard way to enforce the use of a particular custom classloader in a Java EE application, to load classes from a predefined source. There is however the ability to bundle libraries within a Java EE application, so that multiple modules (including web-modules residing in WARs) can load and access classes in the bundled libraries.
The Java EE specification allows an Enterprise application deployment (a .ear file) to bundle libraries in a library deployment directory; by default this is the lib directory within a .ear file. These libraries may then be used by multiple web-modules (located in different .war files) within the root of the .ear file. The relevant part of the Java EE 6 specification is Section EE 8.2.1, where the following is stated:
A .ear file may contain a directory that contains libraries packaged in JAR files. The library-directory element of the .ear file’s deployment descriptor contains the name of this directory. If a library-directory element isn’t specified, or if the .ear file does not contain a deployment descriptor, the directory named lib is used. An empty library-directory element may be used to specify that there is no library directory.
All files in this directory (but not subdirectories) with a .jar extension must be made available to all components packaged in the EAR file, including application clients. These libraries may reference other libraries, either bundled with the application or installed separately, using any of the techniques described herein.
It is important to note that all Java EE compliant application servers (WebLogic/WebSphere/JBoss et al) will support deployment of EAR files with bundled libraries. However, there are servlet containers (like Tomcat and Jetty) which do not comply with the entire Java EE specification; such containers will not support deployment of EAR files.
In the event where the libraries are required to be accessed by multiple web modules in a servlet container (either due to the choice of the container or due to a preference for WAR files), you ought to rely on the servlet container support for shared libraries to deploy the WAR files without the libraries. The Java EE specification does not mandate any requirement in this area concerning the use of installed libraries. Some containers support shared libraries better than others, by supporting versioned shared libraries (where deployed applications may use only one version among several), while others (like Tomcat) do not.
I know that Tomcat uses classloaders to partition webapps, and that the webapp classloader in Tomcat overrides the default classloader behaviour, so that it checks locally for classes and only delegates to the parent classloader if it can't find it.
Knowing this I'm sure that Tomcat will ensure that classes within a .war file is only available to that webapp, since it will be loaded by that classloader.
What I'm not sure about is how Tomcat partitions the core classes, if at all.
I know that Java's core classes are loaded by the Bootstrap class loader.
However, if the webapp classloader trys to load required classes itself first, does this mean the webapp classloader will load the core classes itself?
What I'd like to know is Does Tomcat's classloader hierarchy ensure core Java classes are separately loaded for each webapp, or are they shared between webapps?
If by core class files you are referring to the installed JRE, tomcat shares those with all the webapps.
The separate class loading applies only to the jar files that are placed inside each webapp lib directory.
Even the jar files that are placed under tomcat lib directory are shared between all applications.