Packaging of EJB classes

[PN Kumar]

When the EJB and the rest of the application classes are packaged as two separate jar files(one for EJB and the other for related classes) and deployed on the server side - would the processing of the related classes also have the features of the ejb container such as transaction management,security, networking etc...If so, wont it be better to always package the class files in this manner - one jar for ejb , another jar for application related classes (including DAO classes)?

[Nathaniel Stoddard]

Only the actual EJBs in your ejb-jar file will have the EJBness attributes. As for your other question, it really depends on the goals of the project at hand. Most projects I'm sure would be quite oblivious to the difference in packaging.

[PN Kumar]

Thanks for your response.
The statement "only your actual ejb's would have EJBness features" raises another question. Incase of stateless session beans, the bulk of the processing is done(or preferred to be done) outside of the bean where the "EJBness" isn't available. Doesn't this mean that we are doing away with the "EJBness" when we package as two separate jars with bulk of the processing happening in the non-ejb jar file ?

[PN Kumar]

To further add on to my query, wont packaging the ejb and DAO classes together result in a potential problem - if we need to update the DAO we need to expose a jar file containing EJB's as well ?

[PN Kumar]

Still awaiting a reply....

[Lalita Sattavat]

Packaging stems from the idea of distributing the application. When ejb classes are packaged in a separate jar and other application classes into a separate jar, its done only for easy of distribution. You could have all your ejb's deployed on an enterprise application server whereas Web-app on a web-server. In such a situation you need to place only those classes on the application server that the ejb's shall utilise. Ideally all the classes referenced by the ejb's are packaged into the ejb-jar and others into a separate one since in most web-applications they are used by the web-component. Hence the differniation in packaging. And as far as the the services of the container is concerned, if a class say DAO is being accesses by the ejb, the class by itself does not have the priviledges that an ejb has, however depending upon how the class behaves under various conditions(exceptions, etc) the container shall handle then since its the ejb thats calling the simple DAO class and the ejb is still active.
i hope that answers ur question
Do correct me if am wrong