Richard, When a Java EE server deploys an application EAR, its various components are categorised as modules: Each EJB jar is a separate module Each WAR is a separate module - including all of the jars in it's WEB-INF/lib directory All the jars in the EAR/lib directory are considered as a single module
Each module gets its own class loader. Contrary to popular belief, there is *no* EAR class loader. (Consequently it's not normally possible to read resources from the EAR/META-INF directory, which I've seen many developers attempt). In the absence of any manifest class path settings, class loading works as follows: Each EJB jar module has visibility of all classes contained in jars in the EAR/lib directory EJB jar modules cannot see each other's classes, nor those in WAR modules Each WAR module has visibility of all classes contained in jars in the EAR/lib directory and all classes in each EJB module (this is optional in the spec, but in practice most app servers support this) WAR modules cannot see each other's classes JBossAS/WildFly 7.x relaxes the EJB module visibility rule through default configuration so that EJB modules *can* see each other's classes. Aside from this, JBossAS/WildFly 7.x/8.x is highly spec compliant when it comes to class loading, which has caused a lot of confusion because spec compliant class loading had to be *enabled* through configuration in older versions of JBossAS. In addition to the above, the containers provide access to the JavaSE classes and JavaEE classes*. This means that you should *never* deploy these with your application. In maven terms, API jars used to support builds should have a scope of "provided". This is particularly important in WAR modules because (for historical reasons), classes are loaded from a WAR module *first*, whereas everything else is parent first. * Only WAR modules can see the servlet/jsp/jsf APIs. Some people get caught out by this. As far as your separate EJB jar is concerned, just build it in to the EAR. Life will be easier! Additionally, package your third party jar in the EAR/lib directory. Another common mistake is to specify library jars as jar-modules in the EAR. jar-modules are for EJB client jars (intended to be executed standalone) and are very rare in practice. Hope this helps, Steve C On 12/06/2013, at 1:11 AM, RICHARD DOUST <[email protected]> wrote: > Wayne, > > Thanks for your response. > > I don't really need to make the EJB jar work standalone. I was trying to > divide and conquer. In 4.2.2 I deployed the EJB jar as part of an EAR with 2 > WARs. I think that I'd like to deploy to JBoss AS 7 with an EAR containing > the EJB jar, and two separate wars that use the services of the beans > packaged in the EAR. I'm a little concerned though because I read that if I > go this route, the web tier will be forced to use the remote interfaces while > they currently use local interfaces. Do you know if this is correct? > > Thanks, > > Richard > > On Jun 10, 2013, at 1:05 PM, Wayne Fay <[email protected]> wrote: > >>> Anyway, I'm running into issues at deployment time (just starting with the >>> EJB jar as a >>> standalone deployment) because the EJB jar depends on a 3rd party jar that >>> is not >>> available on the server. >> >> If you **really** need to make the EJB jar work in standalone >> deployment (which is not especially common IME), you could make this >> work with the shade plugin (or other similar plugins) by packaging the >> contents of your dependencies in alongside your own project files in >> an "uberjar" or "onejar." >> >>> I'd like to avoid that this time, so I'm thinking, much like WAR and EAR >>> files have >>> META-INF/lib directories, a jar file might have something similar. Does >>> this fall outside >>> the definition of a jar? Is there no way to package a 3rd party jar upon >>> which one's code >>> depends with one's jar, so that at runtime the dependencies can be resolved >>> by the >>> classloader? >> >> The Java Jar file specification does not allow Jar files to contain >> other Jar files so this is not possible (unless you are using a >> special classloader which does not conform to the spec like >> Classworlds). >> >> Instead, you should be using dependencies in your WAR and EAR pom >> files to declare "this project depends on these libraries" and Maven >> will automatically pull those Jar files in and include them in the WAR >> or EAR packages when they are constructed. >> >> Are you sure that you need this EJB jar to work in standalone >> deployment? Or is this just something you're trying for something to >> do, and you will generally deploy the EJB in a WAR/EAR? If the latter, >> I would ignore this "problem" for now and continue working to make the >> WAR/EAR function as you require. >> >> Wayne >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
