This week's book giveaway is in the Cloud/Virtualizaton forum.
We're giving away four copies of Mesos in Action and have Roger Ignazio on-line!
See this thread for details.
Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Tomcat vs. Glassfish

 
David Brossard
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

A bit of googling didn't really help here.

I am trying to weigh the pros and cons of Tomcat vs. Glassfish.

My initial list of pros and cons:

Pros:
- lighter
- more widely adopted
- easier to use and deploy apps
- faster
- web server (implements servlet / JSP spec only)

Cons
- Glassfish seems richer in features
- Glassfish has management interface to configure many different aspects e.g. jdbc connectors
- Glassfish has built-in scalability features
- app server (implements J2EE spec fully)

Very limited list so far. Any further comments from you folks out there?

Cheers,
David.
 
Jaikiran Pai
Marshal
Pie
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tomcat provides a subset of services than what GlassFish does. Typically these are Java EE services. For example, Tomcat doesn't support EJB deployments where as GlassFish does. Take a look at this FAQ entry http://www.coderanch.com/how-to/java/WebVsApplicationServer for more generic details.
 
Jason Cone
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you compare Tomcat and Glassfish you're comparing a web server to a full-blown JEE app server. The (Tomcat-derived, incidentally) web module in Glassfish is just one of the components of the app container. Tomcat implements the Servlet and JSP portions of the JEE spec. Glassfish implements the full JEE spec, including servlets and JSPs, but also modules for handling container-managed transactions, security, EJBs, asynchronous messaging (JMS), Connectors, web services, RMI, et cetera.

For many applications (e.g., a basic web application and some database connection pools), Tomcat, alone will be sufficient. However, if you need several of the features of the complete JEE stack, then an application server might be a better choice.



 
David Brossard
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for both responses. I do understand that Tomcat is not a full-blown J2EE server. But in the end, what does it mean to be full-blown? Can you add J2EE support to Tomcat by merely putting the J2EE API libs in Tomcat's lib folder and the J2EE implementation inside the targeted web app?
The link to the FAQ was very valuable, cheers!
 
Lester Burnham
Rancher
Posts: 1337
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you add J2EE support to Tomcat by merely putting the J2EE API libs in Tomcat's lib folder and the J2EE implementation inside the targeted web app?

No. You can hook in certain components (like EJB via OpenEJB, JavaMail and JMS via JNDI, JPA runs fine as is, etc.), but Tomcat will never be a full JEE server. Many applications don't need one, though, and what with JPA, JMS and JavaMail being available if needed, having access to an actual JEE server isn't as important as it once was.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic