Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm currently starting a new app development. The app architect insists we use JBoss5 because its "better". Do anyone has a wider definition of "better" (if its the case)?
I have experience using Tomcat5 and 6 in large scale applications with big user loads and it handles pretty well (IMHO). Both would be running over a RedHat6 in identical hardware conditions (in case the implementation matters).
Thanks in advance
To say that any tool or framework is just 'better' is ridiculous. It always depends on the situation, architecture, etc. You don't necessarily want to use a hammer to drive a screw.
I wrote JBoss in Action, so I obviously like the JBoss technology, but I'll be the first to say that JBoss can be overkill in many situations. For example, for the last two sites I've developed, it made more sense to build with Grails and deploy on a standalone Tomcat instance.
Its a bit unfair to say that all you get when using JBoss is EJB and JMS. JBoss offers many services and features, including:
Servlet/JSP container
JNDI
EJB
JTA
clustering
caching
JMS
Datasource / Resource management
JMX integration
OSGi support
web services
portals
Web Beans (Seam)
Some administrative consoles
an IoC container
etc.
The thing that attracts many architects to JBoss is its flexibility. It uses a plugin architecture that allows you to add and remove services. As other have said, in uses Tomcat as its Servlet container, so you can literally whittle JBoss down to where it is practically just a Tomcat server. What is the benefit of doing this? Future proofing if you think that you're going to utilize other features of JBoss.
These services in JBoss come pre-integrated and strive to provide a consistent deployment model that minimizes your effort in writing application logic or configuration to integrate them yourself. That being said, other frameworks like Spring also do a great job of supporting a uniform ways of integrating many popular libraries and frameworks. But since they focus on integrating 3rd party libraries, the interoperability between services is up to you. Because JBoss is building the services and the integration platform, they spend time developing (and providing support) for interoperability.
Some questions to ask when making a choice are:
Are you going to use standard JavaEE architectural components like EJB?
BTW, EJB can be run in standalone Tomcat using the JBoss embedded container, so if EJB is all you're using, then you still don't have to use JBoss
Are you going to utilize Web Services, Portals, JMS?
Are you looking into building with Web Beans or Seam?
What deployment platforms (Tomcat, JBoss, etc) does your IT, support, and development staff currently use? If you are going to use something new, you will incur additional cost to learn the new platform.
If you're selling a product that customers will deploy, what impact will it have on the customers' IT organization.
Are you going to need paid support?
You can find support for Tomcat through many companies (including Red Hat I believe).
You'll need to compare the costs, because I don't think JBoss support is cheap, though I haven't looked up prices lately.
Will you need to do any sophisticated clustering?
JBoss has some wonderful clustering capabilities, and you'll probably get good clustering support through Red Hat. Though, for full disclosure, I've never done any complex clustering with any other frameworks to be able to compare.
Are you going to need advanced transaction management (distributed transactions, 2-phase commits, etc)
Not to sound like a shameless plug, but the first chapter of JBoss in Action is available for free on the Manning website. Though we don't do a direct comparison between JBoss and other applications servers and deployment environments in the chapter, we do talk about the architectural differences a bit, which is relevant to your question.
I'm currently starting a new app
development. The app architect insists
we use JBoss5 because it's "better". Do
anyone has a wider definition of
"better" (if its the case)?
Funny, because JBOSS uses Tomcat as its servlet/JSP engine.
Sounds like "better" means "supports EJBs and JMS", because Tomcat out of the box has neither.
But that's not an issue if your application doesn't use EJBs or JMS.
And if you do need them, you can add them to Tomcat with OpenEJB and RabbitMQ or ActiveMQ.
I'd ask your app arch when the last time they wrote something besides Power Point slides or UML documents. The response might surprise you.
JBoss is an Application Server while Tomcat is a Servlet container
So JBoss may be better than Tomcat in the sense it contains it, plus other components. That's it.
If you're not going to use those other components, you're wasting resources. If you need those other components then Tomcat is not enough.
It depends, probably your Architect has something else in mind.
I wonder what would he say if you ask him directly?
It's not better, it's just more. JBoss includes Tomcat.
As #duffymo points out, JBoss uses Tomcat for its web container so better makes not much sense if we compare equivalent things (i.e. Tomcat and the web container part of JBoss). And if you are not going to use JTA, EJBs, JMS, JMX, etc, there is no real advantage at using JBoss, especially during development (Tomcat is lighter and starts faster, this is often appreciated by development teams).
There are some cases where you could prefer JBoss for production though (I'm still assuming you're not using EJBs, etc):
The production team is trained or used to use JBoss in production, tools (deployment, monitoring, etc) are tailored for JBoss.
The company has a support contract for JBoss (although you can also get support for Tomcat).
But I'm not sure this is what the app architect meant. I would try to discuss this choice with the architect, maybe he has a rationale explanation. And if really JBoss has to be used in production, you can always use Tomcat or Jetty during development.
If you use JBoss, you can pay Jboss.org for support. But it is not the case with Tomcat.
This is true, however RedHat (who bought out Jboss.org) will require you to change to one of their supported versions of JBoss
JBoss is J2EE specification compliant, it supports J2EE specification very well, such as EJB, JTA,JMS, JNDI and etc. Tomcat is only a servlet container, although it also supports a bit J2ee specification. When you want to use J2EE component, you should consider JBoss first.
Forgot a point, JBoss supports JMX very well, especially in version 4.*. I have experienced a project, it doesn't have a web UI, JBoss is used just as a platform and EJB container to integrate all the standalone application on it use MBean.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I know this may be a recurring topic, but I have read a lot of articles and I still have doubts. Also, I would like to hear more recent opinions about this.
The main requirements of my application server are: flexible configuration, support for a extremely high number of concurrent users. It will be a system for the mobile communications industry, so it must have high availability as well.
I am going to develop a Java EE application and Open Source Applications Servers are my only option. I have used GlassFish for a very small project and I really liked it.
My current thoughts:
Small, Fast to start and simple: Jetty
Bigger and more robust and very large knowledge base of users: Tomcat
Bigger again, more features, good
enterprise support, slower to start: JBoss
All can support large user bases and all will do 95% of use cases well.
I'd start by default at the top and move down the list as your situation/requirements get more complex e.g. how much Java EE support you need
Also if you are careful on not using any custom features changing at a later point should be relatively simple.
This is purely based on my personal experience and is a bit simplistic - one could write books on this!
If you're looking for a Java EE server, you basically have two options: GlassFish or JBoss (Geronimo or Jonas just have too small communities and I'm not aware of serious references for them - which doesn't mean there aren't any - I wouldn't pick them). Both are serious platforms, support clustering and HA and have been used to build large scale clusters and offer commercial support if this matters.
Now, a quick summary of the various versions:
JBoss AS 5.1: Java EE 5 certified. Supports HA, clustering, comes with an admin console if you're XML averse (but doesn't support cluster setup through console yet)
GlassFish v2.1: Java EE 5 certified. Supports HA, clustering, better admin console than JBoss 5.1 (especially for the cluster setup, if this matters), great CLI tool.
GlassFish v3: Java EE 6 certified. Very new, doesn't support clustering, centralized administration. Version 3.0.1 to be released soon.
JBoss AS 6.0: Java EE 6 certified. Didn't reach General Availability yet. Can't say much about it for now, M2 might not be representative of final version.
GlassFish v3.1: Java EE 6 certified. Will add Centralized Administration / Clusters, High availability / State replication and more. To be released this year. See the official roadmap.
At the end, if you project won't go in production before 2011, I would consider Java EE 6. If not, then go for a Java EE 5 server. In any case, don't base your choice only on opinions of the web. Download both server, setup a clusters of at least four nodes on two machines (that's a minimum, use a bigger cluster if possible), run a benchmark with a representative proof of concept of your application. And don't hesitate to involve folks from JBoss and Oracle, I'm pretty sure they'll be happy to help at proving their solution is the best one :)
References
For JBoss, have a look at Bela Ban's talk Large clusters in JBoss (pdf) at JBoss World 2009. Also check the sessions from JBoss World 2010. For GlassFish, have a look at their stories and more specifically in the Telco. Contact Sun/Oracle and RedHat for more references.
If you really need Java EE (strictly speaking) then JBoss is a good option. If you don't need true Java EE then you would be well served by using Tomcat. SpringSource also provides an enterprise version of Tomcat with support named tc Server that would be a good option if you don't need true Java EE.
I actually recommend to go with GlassFish. Apart from your familiarity, it uses a NIO network infrastructure (Grizzly) which supports very high number of concurrent connections.
We primarily use JBoss, and I can tell you JBoss5 can support a pretty high number of connections, too (as far as I know, it also uses a NIO based connector).
There is also an EJB container called Resin, which is semi-opensource (basically they have open source version and proprietary version). People say it has excellent performance, but I haven't got the chance to investigate further.
My last point is, are you sure you want to go with JavaEE EJB container? We actually started off with JavaEE EJB container, but because of our performance requirement etc. we are now trying to migrate to Tomcat+Spring. EJB has restriction on threading model etc., which can become unwanted restriction if you have clients other than web browsers...
Until JavaEE5, you have only this "TimerService" for executing periodical tasks, and JMS for doing asynchronous stuff, which is very heavy weight and can become very annoying.
If you're talking full boat Java EE, then Glassfish.
GFv2.1 is rock solid, GFv3 is too young to say, but offers new Java EE 6.
Actively developed, free and commercial support, good forums. Oracle has published it roadmap for it.
It's easy to use, easy to configure, well organized. Great console.
Really well documented, vast amounts of supplementary documents and article from folks working different aspects of it (Metro, Grizzly, JAX-RS, NetBeans, etc.)
NetBeans + Glassfish is a painless out of box experience to get started.
Offers clustering and all sorts of management options.
OK, this is a little unusual, because ANY Java EE container can do the simple things I want to do (XML processing, JPA, Hibernate, SOAP/REST web services, etc). This is for personal use, more to gain skills than to accomplish essential functionality. I have my own Linux server (Ubuntu Jaunty x86_64) with business class internet, so I can install pretty much anything.
I use Tomcat a lot now, however, I ran into a few situations lately job hunting where they were looking for experience in a specific Java EE container (which defeats the whole purpose of having a standard), and of course not the same one each time.
So what I'm looking for is a Java EE server that:
Is in demand in the marketplace right now
Is free (or
Is not too horrendous (disk space, time) to install and to deploy applications on
Runs on Ubuntu x86_64
I've been able to glean some information via Indeed's keyword search, and that tells me to stay away from Jetty/Glassfish, even though they fit "lightweight" and "free". I also see from this SO post that WebSphere is a steaming pantload of bloatware that's hard to deploy/configure, but I don't know if that's accurate or current. I like Tomcat (completely FOSS, smallish, easy to deploy, plenty of docs/users), but it's less in demand than some of the bigger boys.
So what would you recommend I install? Thanks in advance.
My personal recommendation is JBoss. Not only is this a solid server, but there are other JBoss Platforms and Frameworks that easily integrate into JBoss. One example is JBoss ESB.
Far too often, I've seen servers like JBoss and WebSphere (I've worked with them for the last 5 years now) rush to market with broken implementations. Unfortunantely, the part that is broken might be very small, but it will be just what you will be breaking your head on.
Oracle Weblogic just kicked the hell out of me with a broken implementation of MDBs (annotations).
If you want a server that is the most Java EE 5 compliant, will give you the least heartache and pretty much production-worthy, go for Glassfish and yes... use Netbeans as your dev IDE.
+1 on JBoss, that is mainly what I use for personal use and work. I have also used OC4J, and find that it is harder to use, and more finicky with it's class loading mechanism, maybe I'm just used to JBoss. But there is definitely more and easier to find community support for JBoss. So that is reason enough if you are doing this for personal use and are not going to get a support license, there will be many more users willing to help out if/when you encounter issues.
I've only used Tomcat myself, professionally. I've been using it for the better part of my (so far) three year career and I havn't experienced many problems with configuring or deploying applications to it. I use Eclipse WTP for Java EE developers 3.4 (Europa) at work, and mostly develop JSF applications utilizing ICEFaces. We deploy using the Tomcat web manager for most of our smaller projects, and through Hudson for some of our broader applications.
Please bear in mind some caveats, however:
We host about 20 seperate web applications, mostly JSF with a few older JSP apps.
The web applications served by my office have a very, very narrow scale. Our department currently supports about 20 unique users, so most of our applications do not receive a lot of heavy traffic.
Most of our web applications are very processor intensive (i.e. here's a 2GB CSV file...write a program to calculate the total number of people that reside within homes that have 3 or more children...) that only usually perform one-off runs either weekly or daily (or even yearly...). In other words, "Give me all your resources for 2 hours...then I'm going to lunch".
Our primary web server is a Solaris 10 box with a Dual core sparc processor (I believe clocked at 1.8 GHz if memory serves correctly), with 2GB of RAM (don't recall if it is DDR or DDR2).
That being said, I've definitely noticed performance problems over time with regards to our application environment that probably have more to do with our application code as opposed to Tomcat itself. I'm willing to bet that the problems have to do with poor memory management within our processing logic and data allocation than anything. The reason I believe this is because on a fresh restart of Tomcat our applications usually execute in an incredibly responsive fashion, yet over the course of even just one or two days the user experience is degraded.
Take it for what you will. We've probably got some problems to deal with on our end, but Tomcat itself seems to be pretty performant in a localized environment.
I ran into a few situations lately job
hunting where they were looking for
experience in a specific J2EE
container (which defeats the whole
purpose of having a standard), and of
course not the same one each time.
Well, I think you have (half) answered the question yourself! If your primary aim is to help you find a job, you need to look at what Java EE container the recruiters in your geographical area are asking for. Go to your favourite recruiting websites, pull up the Java / Java EE jobs for your area for the last couple of months, and count for each kind of web container. (And also count the jobs that don't specify a particular web container.)
If the results of your research say that you need to learn WebSphere, you have my sympathy :-)
Don't forget that a "mandatory" requirement may not actually be mandatory if you are you are good enough in other areas. It all depends on what other candidates the recruiter can find. Don't be afraid to say "you asked for X, but I have Y and Z which demonstrates that I have broader experience with this technology".
Oracle officially ceased to support Glassfish. All bugs found there (and there are quite a lot of them) will never be fixed.
Payara is now the best option, as this is a clone of Glassfish, but is continued to be developed by the Java community.
Alright, the question might be broad. We've been looking at Jboss and a few other similar app. servers.
From the feature list it would be perfect for replacing our soon to be outdated homegrown reporting application on the server side. But at this point, for 2 developers, just grasping all the setup, configuration, administration, tuning,testing not to mention the APIs and programming itself just seems way too much, too big, too complex.
What path does people take to become familiar and productive with such application servers ?
Start with a simple one, and only use a more complex one if you really need the features.
For example, Do you really need the full JBoss stack? Would Tomcat not be sufficient? It's much less of a handful.
I would approach this the same way I approach anything new.
Start with the documentation - read the introduction and basic setup/configuration documents. Then move on to tutorials and maybe some simple apps that I find interesting. In your case, maybe port a few features over to the new system. As time goes on, you should get better with the tools at hand.
From my experience using one is the best way to learn what you like/dislike about it. Once you have a project set up for one application server it should not be too much work to migrate it to another. I am currently working on an application that we develop & test daily using a simple Tomcat v6 server, but which runs in production on both Websphere Application Server and JBoss.
As a side note for your development, I strongly recommend looking into integrating your Eclipse development environment with your chosen application server through server adapters - it will greatly speed up development tasks and simplify the debugging process.
I'd say that the minimum features for using Java EE are:
Servlets and JSPs, written using JSTL (no scriptlets)
JDBC
JNDI for pooling database connections (optional but recommended)
Basic authentication for security
You can accomplish a great deal knowing just those. If you want to minimize the learning curve, I'd recommend starting with those and staying away from EJBs, JMS, Struts, JSF, etc.
Another benefit is that this subset of features is common to both servlet/JSP engines, like Tomcat, Jetty, Resin, etc. and full-blown Java EE app servers like WebLogic, JBOSS, WebSphere, etc. An app that runs on one should be portable to any of the others, as long as you stay away from app engine-specific extensions.
You should realize that there's a trade-off here. You'll have to develop pieces that might be easier if you leverage the app server more. But hopefully you'll start with some simpler problems and work your way up once you're comfortable with the basics.
There's another approach: Hire an experienced guide to help you with training and mentoring for the first project. A six-month gig with a reputable consulting firm might get you started.
Last of all, I'd recommend Spring. It would also have a learning curve, but it's a good alternative to Java EE EJB development.
I'm probably going to be doing an independent study in College next semester on Java web programming with technologies such as Spring and Hibernate. I'm looking for something that can sit in the corner of my dorm room with out being loud and drawing a lot of power. The machine needs to be able to run a very low traffic tomcat and Mysql server that will allow my professor to see my work with out needing to run a Java app server of his own. I’m considering buying a Sheevaplug and upgrading it with an 8 or 16 gig sd card. I would install Tomcat, Mysql, and either Git or Subversion on it. Is this a feasible setup for what would basically be a server that would have a maximum of two users using it?
I'm running multiple grails applications, eclipse, tomcat, mysql, and a couple other utilities running on a 5 year old windows 2k box with less processor speed, memory & disks space than the plug you link to. I hadn't heard of a plug computer before this post, but based on the specs it sounds like it may be an option given your limited use. While I wouldn't be suggest it for a public facing application. It may be suitable for a limited environment like a home or dorm server for hosting personal applications.
If you do buy one I'd like to know how it goes.
Now I'm considering buying one to try it out myself... ;-)
This looks like a reasonable tool for the job.
You may want to consider this advice from the Debian ARM mailing list, concerning JVM speeds on a similar device:
http://www.nabble.com/Java-%2B-Tomcat-slow-on-TS-109-tt20003260.html#a20015796