Tomcat is a more lightweight container in comparison to Oracle's Glassfish server and has wider adaptability in development for local testing. Glassfish however, as an enterprise product can offer better after sales service to clients.
WebSphere Application Server is propriety and increases project cost. It is slightly complicated to learn when compared to Jboss EAP. These were the two main reasons why we chose Red Hat JBoss EAP over Websphere Application Server. Also, JBoss EAP is light weight and requires …
We decided to use Red Hat JBoss EAP as it lowers our overall cost, supports all the features that we are looking for including clustering, distributed caching and web services. JBoss EAP is modular and has cloud-ready architecture.
JBoss does practically everything Apache Tomcat and Weblogic does in terms of our requirements, but JBoss is more suited for larger enterprise J2EE apps compared to Tomcat. Boot time is not as quick as Tomcat, but still relatively fast for our deployments. The system can also …
Jboss supports JEE standards and provides features like high availability, clustering, hot deployments, configurable features. you can quickly add or remove needed features and cut jboss footprint and reduce boot time.
The benefits outweigh the costs, and the ability to spin up a full cluster deployment for our internal applications on demand has been a game changer. We are able to leverage our engineers' core talents as J2EE developers without them concerning themselves with the infrastructure machinery of managing a highly available fault-tolerant server.
Red Hat JBoss Enterprise Application Platform (JBoss EAP) is well suited for deploying high transaction Java EE based applications. It supports many popular Java EE web-based frameworks such as Spring, Angular JS, jQuery Mobile, and Google Web Toolkit.
MOD_CLUSTER integration. JBoss EAP integrates pretty well with mod_cluster. This is an intelligent load balancer especially useful in highly clustered environments.
Supports enterprise-grade features such as high availability clustering, distributed caching, messaging etc.
Supports deployment in on-premise, virtual and hybrid cloud environments.
When we use the versions of GlassFish Server that were just released to the market, it causes bugs to appear. While there are workarounds to solve them in most cases, the amount of time to solve them is significant. Therefore, I would advise waiting for it to be a little more stable and for a few months to pass before proceeding to an update of a productive environment.
Jboss CLI is a great tool but we had trouble using it to get values that are displayed on Jboss GUI. It also has limitations parsing the applications.xml files and we had to use a mix of jboss-cli and linux bash commands to automate certain application administrative tasks.
JBoss doesn't really provides performance tuning recommendations. It would have been nice if it could learn from the current demand vs current settings for things like connection pool, server configurations, garbage collection etc.
Tomcat is a more lightweight container in comparison to Oracle's Glassfish server and has wider adaptability in development for local testing. Glassfish however, as an enterprise product can offer better after sales service to clients.
WebSphere Application Server is propriety and increases project cost. It is slightly complicated to learn when compared to Jboss EAP. These were the two main reasons why we chose Red Hat JBoss EAP over WebSphere Application Server. Also, JBoss EAP is light weight and requires less server resource
The platform has been stable for us so we do not experience falls or service interruptions. The investment is lower compared to other solutions in the market and we have solid support from Oracle.
Jboss EAP is easy to deploy and configure. This lead to lower cost and faster delivery.
Even though we have large number of machines running JBoss, we have only two Jboss Administrators. It doesn't requires too much administration and maintenance on daily basis and reduces number of administrators required for large implementations.