The ejb-jar file must also contain, either by inclusion or by reference, the class files for all the classes and interfaces that each enterprise bean class and the home and component interfaces depend on, except J2EE and J2SE classes. This includes their superclasses and superinterfaces, dependent classes, and the classes and interfaces used as method parameters, results, and exceptions.

EJB 2.0 Specification 23.3

I have read & re-read the EJB Specification many times over in order to get a good insight, but I have now learnt that only experience can offer clear insights.

The blurb from the EJB 2.0 Specification - 23.3 mentions that the EJB JAR file must
contain the primary EJB Classes ( The Bean Class, Remote & Home Ineterfaces ), either by inclusion or by reference.

I did not pay much heed to the phrase "..inclusion or by reference". I just thought that it may not be really significant in the big scheme of things - I alaways assumed that such phrases are tossed between simple sentences to make them look more "legal".

However, that phrase "...inclusion or by reference" is very very important & I realized it only recently.

I got hold of an EJB EAR file that was packaged in a different manner :-














I always walked on the beaten track & was surprised to see that the classes & the Deployment Descriptrs ( DD ) don't share the same JAR File.

After discussions in Oracle Technology Forums & debates with some of my colleagues ( & of course, reading the EJB Specification late into the night ), I understood that it's perfectly normal to package it in different JAR Files. The WebLogic Application Server used a concept of APP-INF Folder in EAR files to dump some of the application's common libraries.

Well, the meat of the topic here is that at the time of deployment, the EJb classes should be available for the Container. The Container should be able to locate the classes in the application ClassPath. Hence, we can rewire the application classpath & informn the Container about the catucal location of the EJB Classes.

Again, reverting to the EJB Specification 2.0 ( 23.1 ) ,

The ejb-jar file format is the contract between the Bean Provider and the Application Assembler, and between the Application Assembler and the Deployer.

The same works for Servlets & web.xml.

I would defenitely request the authors of the EJB Speicification to keep the language simple ( as in the JavaMail or JMS Specifications ). It would help mid-level developers like myself to get more comfortable with EJBS. It would also motivate the newbies to step into the world of EJBs with more confidence.