Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Java EE scenarios that cannot be handled by Tomcat

Tomcat only implements the web container of the Java Enterprise Edition architecture. In contrast, e.g. GlassFish implements a full Java EE stack. This has been discussed a lot on stackoverflow.

However, for a Java EE beginner like me it is hard to imagine what cannot be done with Tomcat. Could you please give some short examples?

like image 688
Matthias Avatar asked Jun 14 '11 17:06

Matthias


2 Answers

From the Apache tomcat documentation:

Is tomcat an EJB server? Can I use EJBs with tomcat?

Tomcat is not an EJB server. Tomcat is not a full J2EE server. Tomcat is a Servlet container. Tomcat does support those parts of the J2EE specification that are required for Servlets, such as a subset of JNDI functionality. Furthermore, you can connect to remote J2EE servers, or run tomcat embedded inside a full J2EE server.

Some of the differences this implies is...

  • Tomcat can only handle WARs, not EARs
  • Tomcat does not support any types of EJBs (like Session Beans, MDBs, Timers, etc.)
  • Tomcat has no JPA support
  • Tomcat has limited JNDI functionality (not sure of the details here)

Tomcat can be used inside of an J2EE conatiner to use as the web conatiner.

Tomcat is much lighter-weight regarding resources and file system foot prints.

If you need J2EE functionality, my suggestion would be to bite the bullet and use Glassfish despite the complexity and resource requirements (compared to tomcat, Glassfish is quite easy to use compared to others like Weblogic, and JBoss). If not, stick with tomcat, it will keep things simple and fast for you. Either way, it isn't hard to switch your project packaging later and swap out containers.

like image 137
Jesse Webb Avatar answered Oct 15 '22 13:10

Jesse Webb


There are a large number of technologies/capabilities that are part of Java EE. Some of them are available as part of the Tomcat download, others can be added to a Tomcat based environment and some cannot be added to a Tomcat environment.

Deploy an EJB jar onto Tomcat: No.

Call Remote methods of an EJB running in an EJB container: Yes.

Deploy a RAR onto Tomcat: No.

Deploy an EAR onto Tomcat: No.

Deploy an Application Client jar onto Tomcat: No.

Cobble together a way to host a Java Web Startable app that calls Remote methods of an EJB running in an EJB container: Yes

Use JSF as the framework for your app: Yes, but you need to package an implementation in your app or install it onto your server.

Create a program that leverages JSR-88 to manage deployment of war files onto Tomcat: No... not that this is a huge loss.

Use JSR-77 MEJBs to manage your Tomcat server: No... another not huge loss.

Create web apps that provide SOAP web services: Yes... but you will need to get the tools and libraries as part of a separate download and integrate them with your workflow, application and server runtime yourself.

Create web apps that use JPA: Yes... but you will need to the tools and libraries as part of a separate download and integrate them with your workflow, application and server runtime yourself.

Create web apps that use CDI: Yes... but you will need to the tools and libraries as part of a separate download and integrate them with your workflow, application and server runtime yourself.

like image 27
vkraemer Avatar answered Oct 15 '22 13:10

vkraemer