I'm experimenting with EAR packaging. I use the following EAR:
+- ejb1.jar (contains EJBs)
+- ejb2.jar (contains EJBs)
+- app.war (a web app)
The web app uses EJBs from within ejb2, these EJBs use EJbs from within ejb1.
I think the manifest of ejb2.jar must contain the entry
according to the ejb spec. It seems to me that it does not matter for JBoss if this entry is present or not. It seems that it is enough that ejb1.jar is deployed within the same ear file. Is this right? But the classpath entry, nevertheless, should be present to be compliant to the spec? And the behaviour of JBoss should be called an additional feature, shouldn't it?
The same problem seems to be in the web app. Normally, it also should include the ejb2.jar by reference. But where do I place the classpath entry? In a META-INF/manifest file of the web archive?? Again, it seems that JBoss uses ear2.jar in a correct way, without any references.
And, finally, I could create archives with the client view classes of all EJBs (interfaces, dependend classes ...). I can create an EAR with the following content:
+- ... see above
Even if ejb1.jar ALSO contains the client view classes, Jboss does not complain, in spite of the fact, that the client view classes are now present multiple times (in the ejb1.jar and the ejb1client.jar). Maybe this is not a problem because the classes are in different deployment units (two different jar's)? I remember that once I got "linker violations" and "duplicate class errors" but are not sure how the setup was.
Thank you for any comment, Ingo
It seems Jboss looks for required classes in the set of all classes, loaded so far. Is this correct? If so, is this class set scoped to an EAR, and all the EAR's modules participate on that EAR's class pool?
I'm not sure which consequences follows the class loading discussion in the documentation. I tend to think that there is ONE big pool of so-far-loaded classes??