EJB is a technology for the development of distributed applications. The different application servers perform the distribution differently. EJB, CDI, JSP, and JSF are just specifications, and the specific implementations of each container vary greatly. All of them have proprietary, non-portable extensions.
These application servers implement EJB, JSP, Servlets, CDI, and other things, but they do so in different ways. Even in the JSP, each container compiles it in a different way. They are also configured and managed in very different ways and incompatible with each other.
Merely joining a bunch of dependencies with Maven on any application server does not work because each server has its specific dependencies and is incompatible with the others. In this case, you need to put dependencies compatible with the application server in the case. But for this, you do not need Maven, because those dependencies are already there.
For example, Wildfly uses Weld to provide the CDI. If you try to use Weld for this in Glassfish or Tomcat, it will fail terribly.
Tomcat and Jetty are not EJB servers, they only implement the Servlet and JSP part. However, it is possible to use OpenEJB as a Maven dependency to add EJB to Tomcat (and I believe in Jetty too, but I'm not sure). On other application servers, this would not make sense and probably would not even work because they already have their own implementations of EJB / CDI / etc.
In addition, Jetty for example has its own implementation of non-portable websockets for other application servers. The Glassfish COMET package does not run on any application server other than Glassfish.
Jersey is the JAX-RS implementation for Glassfish, while RestEasy is Wildfly. In addition to being JAX-RS implementations, they are also extensions to it. That is, there are things that exist in RestEasy that do not exist in Jersey and vice versa. Attempting to use RestEasy on Glassfish or the Jersey on Wildfly will result in deployment errors. Adding some package to the classpath when using Maven will not solve the problem.
Another strong difference between application servers concerns the use of MDBs. There are different tools that implement message queues for MDBs, and these tools are often coupled to specific application servers.
In other words, all application servers have unique features that can not be added to others through maven (or anything else that puts them in the classpath) because they are tightly tied to details application server that makes it available.
And this is the trap of application servers. The idea of "Write Once, Run Everywhere" and portability are just half-truths. The fact is that in application servers, the code is portable while staying strictly within the standard, but they all have unique and unique libraries, configurations, and mechanisms for each application server that will make your life more difficult if you want to migrate or add dependencies that try to extend the capabilities of the application server.
As for @Inject instead of @EJB , it is because the CDI is younger than EJB. EJB has a dependency injection mechanism that allows you to inject EJBs (annotated with @Stateless , @Stateful or @Singleton ) into locations annotated with @EJB (there are other annotations to inject other things such as @Resource e @PersistenceContext ).
When the CDI was designed, the annotation for dependency injection created was @Inject . For interoperability with EJB, CDI also recognizes @EJB .
