Since Java EE6, it is possible to put in EJBs in WAR files. Is there still any good technical reason to separate them? I am looking specifically for something I can only do with EJB JARs that I really cannot do with EJBs embedded in a WAR.
One may say for modularity, but honestly I find modularity using separate JAR files is a waste of time and extra plumbing and classpath headaches for something that would only be used together (if we do need to separate it later, it is just a matter of refactoring into a separate JAR if needed). Extra dependencies such as guava are different as they are not EJBs.
Another advantage to keeping everything in the WAR is you don't even need an EAR file if you don't want to (aside from setting up the context-root in a standard fashion). The WAR file can contain all the support dependencies such as guava and the ilk.
Another one may be for apps that are not "web apps" which would make sense, but the majority of things I work with are web apps anyway which is why I qualified the question "for web apps".
I am not listing EJB client apps and their interfaces. In reality I would use Web Services rather than something language specific to handle this form of connectivity.
In theory I can do webservices in EJB, but that does not work on all containers specifically websphere which requires you to build a Web Router project which is basically another WAR file.
So is there still any good technical reason to separate them?
No technical reason, no. We did a pretty good job at the specification level in EJB 3.1 where this was introduced to make the transition as smooth as possible.
The one place we fell short is around the topic of the ejb-jar.xml file. A webapp can only have a single WEB-INF/ejb-jar.xml file. This is true even if you have ejbs in jar files under WEB-INF/lib/. If those jars happen to contain META-INF/ejb-jar.xml files, they are ignored.
This was on purpose as the ejb-jar.xml contains the ability to define things in a sort of "global" fashion, such as default transaction attribute, security constraints, default interceptors. It was ultimately decided merging this all in some way was awkward.
I personally expected to hear more complaining than we have -- so far I've heard no one mention that they find only being allowed one ejb-jar.xml for the entire webapp as limiting. However, should people suddenly start complaining, we could introduce a ejb-fragement.xml concept in the same vein as the Servlet web-fragment.xml so configuration could be packaged with the jars in the WEB-INF/lib/ directory.
Certainly, if you're reading this and you have a preference upvote the comment below.