A WAR (Web Archive) is a module that gets loaded into a Web container of a Java Application Server. A Java Application Server has two containers (runtime environments) - one is a Web container and the other is a EJB container.
The Web container hosts Web applications based on JSP or the Servlets API - designed specifically for web request handling - so more of a request/response style of distributed computing. A Web container requires the Web module to be packaged as a WAR file - that is a special JAR file with a web.xml
file in the WEB-INF
folder.
An EJB container hosts Enterprise java beans based on the EJB API designed to provide extended business functionality such as declarative transactions, declarative method level security and multiprotocol support - so more of an RPC style of distributed computing. EJB containers require EJB modules to be packaged as JAR files - these have an ejb-jar.xml
file in the META-INF
folder.
Enterprise applications may consist of one or more modules that can either be Web modules (packaged as a WAR file), EJB modules (packaged as a JAR file), or both of them. Enterprise applications are packaged as EAR files ― these are special JAR files containing an application.xml
file in the META-INF
folder.
Basically, EAR files are a superset containing WAR files and JAR files. Java Application Servers allow deployment of standalone web modules in a WAR file, though internally, they create EAR files as a wrapper around WAR files. Standalone web containers such as Tomcat and Jetty do not support EAR files ― these are not full-fledged Application servers. Web applications in these containers are to be deployed as WAR files only.
In application servers, EAR files contain configurations such as application security role mapping, EJB reference mapping and context root URL mapping of web modules.
Apart from Web modules and EJB modules, EAR files can also contain connector modules packaged as RAR files and Client modules packaged as JAR files.
What is the difference with this xerces144.jar file when it is included in a WAR vs same WAR included in a EAR and deployed.
I think that this has something to do with classloading. When deploying a WAR or deploying the same WAR inside an EAR, Weblogic doesn't create the same hierarchy of classloaders.
The strangest part is that Weblogic 9.x ships with Xerces 1.4.4 in 3rdparty.jar (at least, this is true for 9.1, it would be interesting to check the version for 9.2). This can be easily verified by running the following command on the command line:
$ java -cp 3rdparty.jar org.apache.xerces.framework.Version
To be honest, I don't know what happens exactly and what the problem actually is when you deploy the WAR inside the EAR with Xerces packaged in the WAR. In all the scenarios you described, my understanding is that there is a Xerces jar somewhere on the classpath.
If you really want to deploy Xerces-144.jar in the WAR, could you try to set prefer-web-inf-classes in the weblogic.xml
and test this configuration?
Best Answer
If you have JAR files that you need to share between multiple WAR files or between WAR files and EAR files then you will need to package them in the EAR.
If WAR#1 has a JAR in its WEB-INF/lib and is packaged in an EAR with WAR#2, then WAR#2 will not be able to see the JAR files in WAR#1/WEB-INF/lib.