EAR and dependencies

On the new project our team decided to make a switch from spring to ejb3.
We have created the EAR project, web module and ejb module. We have faced with a problem of classpath. Here is a cheat sheet of organizing the EAR project:

JEE Modules

Java EE applications consist of five primary elements: Web modules, EJB modules, application client modules, resource adapters (RAR files), and utility JARs.

Utility JARs contain code used by both EJBs and servlets. Utility frameworks such as log4j are good examples of a utility JAR.

EJB modules, utility JARs, resource adapter files, and shared libraries associated with an application are always grouped together into the same class loader. This class loader is called the application class loader. Depending on the class loader policy, this class loader can be shared by multiple applications (EARs), or be unique for each application, which is the default.

By default, Web modules receive their own class loader, a WAR class loader, to load the contents of the WEB-INF/classes and WEB-INF/lib directories. You can modify the default behaviour by changing the application's WAR class loader policy.

Guidelines for organizing project dependencies

Compile-time and runtime class loading may not be identical.

At run time, your applications must follow the J2EE specification when referring to other modules.
The solution is to make use of the fact that J2EE modules are JAR files. All JAR files may have a META-INF folder that contains a MANIFEST.MF file, and the manifest file may contain a classpath that refers to other JARs. By adding one of the other modules as an entry in the manifest's classpath, the current module can make use of its contained classes. You can also add JAR files from within the enterprise application to the manifest. The only restriction to this otherwise simple solution is that, since Web modules are not structured with classes at their root, other modules can never depend on classes from within Web modules. In other words, no modules may use the manifest to depend on classes from within a Web module.

1) If your JAR file is only used in a single Web application, always put the JAR file in the Web project's webApplication/WEB-INF/lib folder. JAR files in this folder are automatically added to the Java build path, and will not require any further setup when moving to a different server.
2) If the JAR file is used by multiple modules within the same application, put the JAR file in the enterprise application.
Java archives that are referenced by classes in EJB modules can be kept at an EAR level shared library.
Dependencies at the EAR level are visible to both web and EJB modules.
3) There could be scenarios where an application EAR can have duplicate Java classes in both the EJB and web modules. These duplicate classes can be kept in a separate common module, referred to as the Java utility module.

Some more information can be found http://www.ibm.com/developerworks/websphere/techjournal/1205_chandra/1205_chandra.html .