This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have an application (EAR file) that has a webmodule and an ejb module. Both these modules use log4j. Hence i have this jar in the EAR/lib directory of the ear file. When i deploy the ear file and try to access an action class (in the web module) that uses log4j, i'm getting a noClassDefFound error. If i explicitly reference log4j.jar (that is in EAR/lib) from my MANIFEST.MF classpath for the web module, it works fine. Same is the case with EJB module.
Here is my concern -
Isn't it true that the EAR/lib contents are loaded by the application classloader which is a parent of the web module classloader. If so, why the explicit reference again?
You are correct in your understanding that a web module class loader is a child of an application class loader. However, without a MANIFEST.MF Class-Path entry, EAR/lib/log4j.jar is unknown; It can not be automatically added to the classpath, and therefore you get a NoClassDefFoundError exception. This is not peculiar to WebSphere, but is characteristic of all J2EE conforming application servers. See section 8.2 of the J2EE 1.4 specification.
Because utility jars are loaded by the application class loader (same class loader for the EJB modules), the log4j.properties file in the EJB module will be used, even by your web module. This may be what you want. If not, you could uniquely name the properties files (e.g. war_log4j.properties, ejb_log4j.properties), place them in another utility jar (don't forget the Class-Path entry), and load the appropriate property file in each module.
Originally posted by Bill Lasley: [QB] However, without a MANIFEST.MF Class-Path entry, EAR/lib/log4j.jar is unknown; It can not be automatically added to the classpath, and therefore you get a NoClassDefFoundError exception. [QB]
I'm still unclear. The following are my pain points -
1) Isn't it true that when a classloader loads a class, its available as part of the classpath?
2) Isn't it true that all the jars mentioned in EAR/lib are loaded by the application classloader? If this is true, won't they be readily available in the classpath for the web module classloader? Then, why the explicit reference in the manifest again?
The example that i initially mentioned has a classloader policy (MODULE) and mode as (PARENT_FIRST). Doesn't this mean that i'm going to look up to my parent to load things (make appropirate classes in scope, available) before i load mine?