EJB is a technology for developing distributed applications. The different application servers perform the distribution differently. EJB, CDI, JSP and JSF are just specifications, and the container-specific implementations vary widely. They all have portable proprietary extensions.
These application servers implement EJB, JSP, Servlets, CDI and other things, but do it in different ways. Even in JSP, each container compiles it in a different way. They are also configured and administered in very different ways and incompatible with each other.
Simply merging a lot of dependencies with Maven into an application server does not work because each server has its specific dependencies and incompatible with the others. In this case, you need to put the application server-compatible dependencies in the case. But for that, you don’t need Maven, because those dependencies are already there.
For example, Wildfly uses Weld to provide 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 implement only 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 as well, but I’m not sure). On the other application servers, this wouldn’t make sense and probably wouldn’t work because they already have their own EJB/CDI/etc implementations.
Moreover, 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 implementation of JAX-RS for Glassfish while Resteasy is the implementation of Wildfly. Besides being implementations of JAX-RS, they are also extensions of it. That is, there are things that exist in Resteasy that do not exist in Jersey and vice versa. Trying to use Resteasy in Glassfish or Jersey in Wildfly will result in errors in deployment. Adding any package to 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 Mdbs' message queues, and these tools are often attached to specific application servers.
That is, all application servers have features exclusive that cannot be added to others through Maven (or anything else that puts them in the classpath) by being strongly tied to internal details of the application server that provides it.
And that’s the trap of application servers. The idea of "Write Once, Run Everywhere" and portability are only half-truths. The fact is that on application servers, the code is portable while staying strictly within the standard, but they all have libraries, specific and unique settings and mechanisms of each application server that will make your life difficult if you want to migrate or add dependencies that try to extend the application server’s capabilities.
As to the @Inject in place of @EJB is because the CDI is younger than the EJB. EJB has a dependency injection mechanism that allows injecting Ejbs (annotated with @Stateless, @Stateful or @Singleton) in places noted with @EJB (there are other notes to inject other things, such as @Resource and @PersistenceContext).
When the CDI was designed, the annotation for the dependency injection created was the @Inject. For interoperability with the EJB, the CDI also recognises the @EJB.
First, there are two different questions here. The first is that application server is neither football team, each has its own preference. In addition, the various application servers are quite different from each other (Tomcat, Jetty, Glassfish, Wildfly, Websphere, etc), so you have several different options for various different tastes. As for the second part of your question, I think this should clarify: https://stackoverflow.com/q/4684112/540552
– Victor Stafusa
I appreciate your reply. I understand that there are several different Application Servers, but the concept of Application Server is general. It is a complete tool that provides support for all frameworks I mentioned. The point is that I can use all of them in my Servlet Container (Tomcat 8), which according to many posts I have seen on the internet, does not support such technologies, being limited only to JSP/Servlet. Hence my question. The "support" provided by Application Server is only to bring with it the dependencies I had to import from Maven?
– Thiago