#Difference between glassfish and tomcat full

The official documentation is extensive and complete (20+ books, from Developer's Guide to Deployment Planning Guide). Technical information for GlassFish comes in various forms complementing one another quite well. GlassFish also comes with a self-monitoring framework capable of implementing administrative rules such as the addition of a new node to a cluster if the average response time goes beyond a certain threshold. GlassFish also provides a fully- integrated monitoring feature called Call-Flow which reveals very accurately where time is being spent in the application before a response is sent. All is JMX-based, exposed using MBeans (called AMX) and usable from JMX tools such as JConsole or the new VisualVM (specific plugin for GlassFish there). From web tools to command- line tools, GlassFish has an extensive set of features ranging from application (un)deployment, to JNDI resource creation, to all sorts of configuration details. Admin ToolsĪdministration and monitoring tools is what GlassFish users coming from Tomcat get as an immediate benefit. Java EE 6 profiles should help improve that situation for the industry as a whole.

#Difference between glassfish and tomcat full

Tomcat is not a full blown application server so while it may be enough for some developments, many companies find themselves maintaining a stack of frameworks and libraries on top of Tomcat when a GlassFish provides a JPA persistence engine (Toplink), a full web services stack ( Metro), an application model (EJB3), and more, all out of the box. This allowed developers to enjoy the much simplified EJB 3.0 specification, JAX-WS, and more goodness early on but it also provided dependency injection in the web tier (in servlet or JSF managed beans). It delivered its first Java EE 5- certified implementation more than two years ago. Support for Java EE 5 (and soon Java EE 6) has always been a key priority for the GlassFish project. Finally, Grizzly is the key technology for implementing Comet (aka Reverse Ajax, aka Ajax Push) which enables so very interesting push scenarios (from server to clients).

Grizzly is also used for other protocols such as IIOP and now SIP ( project Sailfin). While using Apache or Sun Web Server in front of GlassFish is quite possible, it's certainly no longer needed for performance reasons. It's a 100% Java nio framework that provides the same performance as Apache only it's written in Java and integrated straight into the application server. Since GlassFish v1 (May 2006), Grizzly is the HTTP frontend of the application server. Historically, if you wanted to get good HTTP performance from Tomcat you really needed to have a the Apache web server to sit in front of Tomcat which involved more setting up and extra administrative work. Tomcat, it's probably useful to know that Sun is the original creator of Tomcat and that any application running today on Tomcat should run just fine (no modification whatsoever) on GlassFish. While there are indeed several advantages to using GlassFish vs.