Stop Wasting Money On WebLogic, WebSphere, And JBoss Application Servers

Use Apache Tomcat. It is free.

I don’t understand why firms spend millions of dollars on Java application servers like Oracle Weblogic or IBM WebSphere Application Server. I get why firms spend money on Red Hat JBoss -- they want to spend less on application servers. But, why spend anything at all? Apache Tomcat will satisfy the deployment requirements of most Java web applications.

Your Java Web Applications Need A Safe, Fast Place To Run

Most Java applications don’t need a fancy container that has umpteen features. Do you want to pay for a car that has windshield wipers on the headlights? (I wish I could afford it.) Most Java applications do not need these luxuriant features or can be designed not to need them. Many firms do, in fact, deploy enterprise-class Java web applications on Apache Tomcat. It works. It is cheap. It can save tons of dough.

Expensive Java Application Servers Sometimes Add Value

There is a need for luxury. But, you probably don’t need it to provide reliable, performant, and scalable Java web applications. Application server vendors will argue that:

  • You need an application container that supports EJBs. EJB3 fixed the original EJB debacle, but why bother? Use Spring, and you don’t need an EJB-compliant container. Many applications don’t even need Spring. EJBs are not needed to create scalable or reliable applications.
  • Optimized application servers optimize hardware. Some of the vendors say that total cost of ownership (TCO) is cheaper because they contend you need less hardware to support the same volume. The problem is that most of those benchmark tests are orchestrated to exercise every feature provided by the feature-rich application server but not the common Java web application. Prove me wrong. Show me a benchmark of a Java web application that calls servlets. And don’t fool me with database connectivity optimization, or transaction processing, etc. For a large number of servers, hardware optimization may be improved, but only for certain circumstances. The JVM you run is far more important. For example, Oracle built JRockit into its middleware.
  • Two-phase commit is serious. IBM says that they have the best two-phase commit capability in the market because they understand transaction processing better than anybody. I cannot argue with that. IBM is awesome when it comes to providing a two-phase commitment that is second to none. However, many apps do not have two-phase commit and could be designed without the need for it. If you need two-phase commit, then IBM WebSphere is the top candidate, but both Weblogic and JBoss provide this capability too. Most Java web applications don’t need two-phase commit in my opinion.
  • Manageability. Manageability is super important, but all I want to know is: 1) Is the server up; 2) is my end-user performance acceptable; 3) has my fault-tolerant architecture kicked-in to solve either problem? Application architecture can be designed to auto-detect issues with availability and performance using tools such as Compuware Gomez and open source monitoring tools such as Nagios.
  • Clustering supports scalability, performance, and availability. This is probably the best argument for the application server containers because enterprise web applications must be scalable, performant, and reliable. I am a huge fan of stateful web applications. Why not? For Apache Tomcat and for the other products I highly recommend elastic caching platforms (ECP) since it is a technology that is independent of the application server and super-fast. In fact, IBM has WebSphere eXtremescale, Oracle has Coherence, and Red Hat has Infinispan.
  • Apache Tomcat is a toy. I question even the need for a container. Seriously, why can’t Java web applications just run on the operating system like the containerless Microsoft .NET applications? The answer is: Then we would not be able to sell hundreds of millions of dollars in application servers. Remember when Netscape sold Web servers for $50,000 a pop? No one buys a Web server now. I think the application server bubble is about to burst.


If you are already deploying large-scale Java web applications on Apache Tomcat, then you already know what I am talking about. If you are considering a new Java application server strategy, then consider these options:

  • Existing Java web applications. Do your Java applications really need Weblogic, WebSphere, or JBoss? Ask your developers. They may actually already develop and test the applications on Apache Tomcat that is embedded in their integrated development environment (IDE) such as Eclipse. How will the applications perform, scale, and be highly available running on Tomcat? The answer is probably already architected in your existing infrastructure with a load balancer and monitoring tools.
  • New Java web applications. Tell your developers that you wish to deploy the applications on Apache Tomcat. They will probably be thrilled. Just make sure that they incorporate an elastic caching platform (ECP) for applications that must be highly available, scalable, and fast.
  • Spend the savings on better development tools. Faster application development and change is a key megatrend. Instead of wasting money on bloated deployment options, spend the saving on tools for faster development such as business rules platforms, business process management, and business event process. IBM, Oracle, and Red Hat all have development tools  in these categories as well as many other vendors.
  • Public and private cloud -- elastic application platforms. Traditional application servers or containers such as Tomcat will fast become legacy methods for deploying Java applications. The next generation is elastic application platforms (EAP) that are containerless. Instead, these platforms take advantage of public or private elastic infrastructure. For example,  GigaSpaces with XAP, Red Hat with OpenShift, VMware with Cloud Foundry.

What is your opinion? Make the case for your favorite deployment option.


Remember $50k Netscape servers

Remember when Netscape Corporation could charge $50k for a web server that implemented the HTTP protocol. The functionality of Web servers has been bundled in operating systems now. The result: You would never pay good money for a Web server. That's where we are with Java Application Servers. I have always been shocked that an application server was necessary at all. Applications should run on operating systems that have all the required services? Sun Java architects could have built all these services into the JVM. They didn't because they needed an ecosystem to push Java and that ecosystem needed to make money

>Sun Java architects could

>Sun Java architects could have built all these services into the JVM

They could, but it wouldn't be a smart idea. The distinction between Java SE and Java EE is basically the first attempt at making the platform more modular. Nobody would have wanted a Servlet Engine and Web MVC framework to be present in every JRE intended to run a desktop app (like the other way around every headless Java server has the graphical AWT and Swing libraries present).

>They didn't because they needed an ecosystem to push Java and that ecosystem needed to make money

And you really believe that all the choices Rod Johnson made was out of benevolence and he never intended to make a single buck?

Anyway, the problem with this entire article is that it's some kind of old resonance of the sentiments that existed in the first half of the noughties. Java EE (J2EE back then) was heavyweight, expensive, corporate, bloated, vendor driven and closed source.

Fast forward a little more than half a decade and there's a Java EE that's lightweight, free as in free beer, community driven, slimmed and trimmed and open source.

Modern Java EE implementations start up in seconds, are measured in tens of megabytes instead of in hundreds or even gigabytes, and have mostly thrown away the invasive heavyweight model of required framework supplied base classes, interfaces and tons of XML in deployment descriptors. Instead there's typically nothing more than a single annotation on a POJO. Configuration files have been made completely optional in most cases. See e.g. and .

The article largely rehearses arguments from many years ago as-if it was still 2005 and J2EE 1.4 was still the latest version. While these kinds of articles were valid back then, they aren't anymore and many people have learned this. Very often people who rant against Java EE indeed haven't tried it since the J2EE 1.4 days and are completely oblivious to the huge advances made since then.

I couldn't agree more. Java

I couldn't agree more. Java EE today is light-weight, fast, modular and based on microkernel architectures. Everything that you had to plug in to Tomcat years ago is now included in Java EE 6 application servers and works out of the box. Even the standards have made a huge step. The author obviously hasn't tried any Java EE technology recently.

Use Netty for very high load

A recent challenge was launched in France to support very high load (210000 simultaneous connections) ... One of the key conclusion is that Apache was not the right choice, but Netty was. Optimizing the JVM and the Unix system was also key ...
They all used caching system to reduce load on the DBMS.

The problem was never on the dev side (except that not so many architects can build a java system supporting very high load), it was only on ops side. Those guys like the "beautiful admin interface". You do not have it with Tomcat. Nagios is very very light ... You will need add-ons.

And be ready to spend lots of time to learn, tune and value Tomcat. It comes at a price. But after, you can automate and use tools like puppet and chef .. And the solution is future proof, ready for the cloud ...

Whatever the architects want, the dev wants, ops always win since they own/manage the datacenter (hardware and network) and do the system updates. As usual, technology is not the issue.

Very high load

Thanks for your valuable insights for very high load applications. Netty looks like it was designed for high connection. Can you give us a couple of reasons why you picked Netty and pros/cons? Thank you also for your insights on using puppet and chef to make ops smoother.

Netty for non blocking IO

Netty is really useful for java apps that needs to manage lots of concurrent connections. The web server uses non blocking I/O and an event model. Of course it requires more tunning and your need to apply some patterns for benefiting from it ...

I can not say more, sorry.

Netty vs. apache MINA

Hope this could also help ...

netty is a a java api and can be used also on the client side.

Finally, lots of people are also using tomcat with the NIO connector (available since V6).

So Netty is better suited for people wanting to customise all aspects of their client/service/server systems. For the others, the ones that will rely on the server side, use Tomcat and test NIO connector.

We just went through this

We just went through this whole thing at the State of Iowa. Once upon a time an IBM salesperson convinced the technicians and management here to buy their full Java stack. Since then virtualization has made WebSphere problematic because, as it turns out, we can meet 99% of our needs with PHP or .NET applications. We finally ported everything in WebSphere to Tomcat to put it on even footing with PHP and .NET. No more WebSphere licenses, now we can virtualize Java and now we can stop treating Java as the PITA it use to be.

And it opens rooms for continuous integration

Liferay was also very difficult to install on WebSphere. And we can generalize this comment to lots of open source software.

With Tomcat, we were able to give a server to all our developers, since you do not pay for dev and QA licenses. The result, massive adoption of continuous development, great improvement of code quality (maven, Hudson, Sonar all free) and more easy QA. If I remember well Sonar now support PHP and .net ...

We also decided to stop using Java app server clustering and moved to farm of Tomcat servers, and load balancing (with sticky sessions or not) done by BIG IP.

Use JBoss. It is free, elastic, and better than Tomcat

I agree with the elastic caching needs, and cloud support. It has those same nice features, just better, and no they are not tightly integrated: while Infinispan is awesome you can replace it with anything you want. Also Infinispan is not bound to the JBoss application server and it can be run independently.

It's true that most applications won't need all the luxury you listed, but it's nice to know that in case I will need it - specs change all the time - I could start using those services; when an application matures it is quite likely that at some point I need a second datasource, and suddenly I won't be able to do that since I can't do XA.
It's also true that free is often my choice, especially during development, but again it's nice - sometimes crucially important - that we have the option to get a certified and supported platform.

I agree in concept that

I agree in concept that "two-phase commit is serious" in that we need ways to incorporate multiple datasources in transactional ways. But in practical usage, coding 2PC often increases development time and produces brittle code that is difficult to test. We need to start thinking of new ways to transactionally scale-out the data layer both in-memory for fast access as well as on disk for reliable persistence.... and this is NOT an "either or" kind of choice. 2PC is 20+ year old technology whose time has passed.

You had me at "I don’t

You had me at "I don’t understand why firms spend millions of dollars on Java application servers..."


Maybe we could help pay off the national debt with the savings. :)


One key point you missed is support. Companies with share holders cannot sustain the risk of unsupported software running their business.
It is true that you can buy in 3rd party support for tomcat but then why pay people who didn't contribute to it.
Companies like Red Hat provide you with "enterprise" versions of the software (JBoss) where they have rigorously tested it and they take the liability if it goes wrong.
I'm not saying that I disagree, I'm sure loads of companies use paid for containers when they don't need to, I'm just saying this would be a top reason for buying one even if you don't need the features.


Granularity of support

Jame, Great point about support. I guess it depends on what level of support is actually needed. I have a binary view of any particular Tomcat version. It either works or it doesn't. Of course, that would require regression and load testing on any new version of a platform that is used including the commercial products. There is a probably an argument to be made that the commercial products like WebLogic and WebSphere have more features and more moving parts so have a greater need for support.

Support is Overrated

If Weblogic and Websphere worked as advertised, you wouldn't need support. At least with Weblogic, it seems like versions are released based on marketing schedules and not development schedules. Just look at all of the patchsets that follow a release. If free products had this many bugs, no one would use them.

Also, for all but the most basic questions, paid support is worthless...even if you follow the escalation procedures. For every 5 tickets that we open, I would estimate that we solve 4 of them before support does. It would scare the bejesus out of me to depend on a support channel during an outage of a mission critical application. Regardless of whether your using a paid app server or a free solution, you better have the talent in-house to resolve even the most complex issues.

We too fixed our own problems 99% of the time

My experience as well with both Fortune 100 and Fortune 400 firms, in almost every case those of us in the trenches analyzed, designed and implemented the fix before any Support company (MS, IBM, others) got back to us with a solution. In fact in most cases they never got back to us with any viable solution in spite of us paying allot for support.

Even worse instead of telling us they did not have a solution, they would provide a bunch of useless steps that never would work (.. realized this after the third time through 1 20 - 30 page "solution" to our problem ~ NOT), of course they said it would work. The only reason I attempted it a third time is that a VP in the company could not believe that we were provided with a non-solution. Of course the support company was telling them it worked for them...liars.

In 99% of the cases, the only reason the company wastes money on support contracts is because of a weak links need for CYA. Rely on support companies for mission critical products, I shudder at the thought. Much more intelligent to have professionals in the trenches you can count on.

In one case where the support company did provide a solution, it had to violate network protocols to even work, that was a hoot! Ultimately we provided them with the data and had a "solution" working weeks before they finally got back to us...amazing.

I pause to consider what would have happened had we waited for weeks for a solution to our problem, that would not have been good. I doubt I would still be working there, whether I wanted to or not.

Fully agree

I don't think there is any reason left for App servers.
I use Spring for my plumbing.
I use Atomikos to have distributed, and if ever needed, XA transactions available.
If I need clustering there is Hazelcast and Terracotta to help me.
I don't even need Tomcat or (not fully correct) Jetty as I just run up a Camel http route to listen to web requests (which in turn runs up an embedded version of Jetty).

Upside: Debugging is simple and I save myself the fights around dependency versions of JTA, Hibernate etc. when I try to deploy my app to a container ....

Cool - container-less applications

Thanks for letting us know about this alternative deployment option. I especially like that you mentioned Hazelcast because it is a great technology but not that well known.


The current application I am working on I actually developed in hybrid mode, allowing it to be deployed as a war/ear as well as as a standalone application.
The main advantage for me is that it simplifies and fastens development speed as I can debug the application as a standard standalone java application from within the IDE, whilst still being able to deliver the desired ear files to our customers.
Testing is also significantly easier.

Java EE 6. Learn it. Whether

Java EE 6. Learn it. Whether it is better or worse than Spring is mostly your opinion. THE reason for a Java EE Application Server is that it provides the full Java EE specification. With Java EE 6 this provides practically all of the useful features of the Spring Framework and all managed by the container. No more wars/ears bloated with the entire Spring Framework. At least stop being so damn ignorant before you declare application servers as dead.

I agree with Brandon. Java EE

I agree with Brandon. Java EE 6 is an absolutely great product that has a very lightweight programming model. It's full stack, meaning it's not just a bean container or a persistence provider, but contains all the common things the majority of applications need in one coherent package.

It's the same kind of approach that for instance Ruby on Rails also takes.

Sure, you can build your own stack by cobbling together various libraries from various places, but it's a pain to maintain in the end. Compare this with building a Linux distro from scratch. Sure, some people do it and get great results. The rests just downloads Ubuntu.

Your wars and ears remain small if you target Java EE, since you don't include an entire AS (which is what Spring really is) INSIDE your war. If you're really eager to statically include everything in your war, why then also not include Tomcat? Why not include the JDK itself?

Yes, why not? I like the idea

Yes, why not? I like the idea of an embedded servlet container included inside my jar!
Does the size of the jar/war matter? At least I know that what I delivert will work together. It's running the same configuration in which I developed it inside my IDE.
The point stays - the container does not offer me any advantages I can't get without it.
On the other hand if you deliver software to customers running a variety of app servers of different versions of the JEE spec as I have to - trust me you will start to hate them with a vengeance.

Thanks for the gentle hint at

Thanks for the gentle hint at that it should be jar, not war ;)

Anyway, there was an article on dzone about this the other week:

Basically you're right, you can consider "servlet container + tons of libraries for whatever services + your own application code" as one deployable unit. But in the same line of reasoning, you can also consider "Java EE AS + your own code" as one deployable unit then.

Resin for example is a complete implementation of the Java EE 6 Web Profile (it even implements some additional features from the full profile), yet it's barely larger than Tomcat. Put this together with your application code in a jar and you have an even simpler setup. The burden of combining various libraries to form a stack is then mainly on the shoulder of Caucho (who deliver Resin).

There's btw also something to say for one of the last comments on the dzone article. Why not ship the JDK and entire OS to your customers as well? Give them a complete virtual machine image.

But also don't forget that a LOT of people develop for a single company where the software they create is only run by that single company. The issues you encounter (and which I don't want to downplay, since I know they exist) are completely not relevant in that case.

There are a small amount of differences between Java EE servers, and porting an app from say JBoss AS to Glassfish is typically a matter of days (different syntax for JMS destinations and data sources, perhaps the odd Hibernate specific annotations used somewhere, etc). However, supporting a lot of configs simultaneously with the same code base is an area that's open for improvement.

Not that many companies spend

Not that many companies spend money on Application Servers like WLS/WebSphere _only because they need a fantastic App Server_. For instance the WLS features like the Admin console or embedded Coherence, the Session replication model and much more are really great - and no, thats not Tomcat + Spring by a wide margin, but is it worth 5-digit fees per CPU-Core?

The common case is, that Companies buy products or product suites, e.g. the Oracle SOA Suite or IBM Portal Stuff - and this products run best with the same companies App server (there are also support reasons in this scnarios). If you look into the product catalog of Oracle or IBM, than you know why they sell this many App servers ;)

I would say, this topic is overrated. You could ask, why People use JBoss Appserver or Glassfish instead of Tomcat + Spring, but thats another matter and has nothing to do with buying or not buying some software.

Best regards,

Andre, I fully agree with the

I fully agree with the fact that companies buy product suites and expect Java software to be installed on those suits' Application Server.
We deliver our software to large enterprises and, yes, we will have to assure our software ca run on their app servers.
I do however feel the reasons for doing so need revisiting - all of the advantages of an application server can be achieved by now without a container. Inclusive of the ease of maintenance.
On the other hand we do still have issues creating EE applications that are really portable.
Added to the differences between vendors is the fact that these same enterprises will upgrade the versions of their Application servers at their own, and often very slow, timetable. This means your software needs to be able to deploy on different EE versions as well.

Paid Support

I work in a shop that has a heavy committemnt to Websphere. They don't need it. they have no EJB's at all. The dev server we use is Tomcat. The management wanted to know why I was using Tomcat. I said caz it works, it's all we need and it is easy to use. but who will support it they asked? Me! We can buy a book and train your sysadmins on it. But what happens if something goes wrong? We fix it.

Many times it is the support boogie man that is brought up to discourage Open source tools. It is just something we have to deal with..... and yeah, the bubble has burst!

Support boogieman

Well said Ivan.

You can't be serious. Blaming

You can't be serious.
Blaming a company for using 10% of an expensive product is one thing but arguing like you did about support is ridiculous.
So you guys are expert enough to debug and fix potential bugs in Tomcat, what about Spring ? Hibernate ? Seam ? I guess you feel able to debug and fix whatever framework/platform you use. Also able to help and train the entire development team?
With such a skill set, you must be expensive. So what's your annual cost ? Because training, helping, supporting, fixing can quickly be a full time job on big project or in enterprises where there are critical applications, in a big company with many parallel projects, dozens of deployed apps one people isn't sufficient.
I guess you've been hire/paid to design/implement/release critical projects so what happens if you get late because you are fixing a quite tricky bug in Tomcat? What happens if your fix is triggering 2 new bugs in production 2 days later? What happens if the bug is raised when you are on holidays ?
Now please grab your calculator and use your brain to balance the global costs and compare the risks.
Maybe you are technical gurus but certainly not good in taking enterprise strategic decisions, your idea of support doesn't scale.
Often, support contracts are mandatory (not only related to app server) for a company, it considerably reduce the risks and reduce the costs compared to having internal people dedicated to it.

a quite tricky bug in Tomcat...

...will be fixed from the "real FOSS" community!!!

In all other cases, you will be trapped in the the "Vendor lock-in hell"! If it's IBM, Oracle, JBoss,...

That means further, that the "technical gurus" are making the real competitive strategic decisions for their enterprises, whereas the others ('unscientific nontechnicians') didn't even know what they are buying!

"Seriously, why can’t Java

"Seriously, why can’t Java web applications just run on the operating system like the containerless Microsoft .NET applications?" Seriously, if one has ever built/deployed a .NET web app they will know not to say that. First, .NET web apps run in IIS - a container. Sure you can hack something up to not use IIS. But then there goes your "seemless" security. To top it off, the IIS version is tightly coupled to the Windows Version as is the .NET version. Developing an app on Win 7 and then deploying to Windows Server is not just dropping the web app on the server. Also, try creating a WebGUI, Spring.NET and NHibernate app and just deploying it the latest version of IIS.

As for Java app servers - I have used many different ones. But recently only Tomcat, JBoss, Jetty and Glassfish. Could I run without them? Yes. But my efforts are better spent elsewhere.

Seriously? Get it

Seriously? Get it right.

Tomcat and Jetty are servlet containers. JBoss AS and GlassFish are Java EE Application Servers. God Fucking Dammit people, either learn what the fuck you are talking about or shut the fuck up.

Still invest in java EE?

Great to see that even on Forrester blog we can find a troll...
Is there still people that continue investing in Java EE ? Seriously?
With IBM or Oracle as app servers?
You really impressed me.

If you are talking to me, I

If you are talking to me, I have no idea what you mean. By my last statement I only meant i don't have time to build and assemble my own "container". So If i only need Jetty then i will only use Jetty. I have not needed nor used the big vendor Java EE Application servers in years. As for investing in Jave EE... are you saying you don't need anything that the Java EE spec provides?

>Is there still people that

>Is there still people that continue investing in Java EE ?

Of course there are! Java EE is a really great technology, especially now Java EE 6 is really starting to take off.

JSF 2.0 is one of the best web frameworks out there right now. Really powerful, with lots and lots of freely available components. Facelets templating works like a charm, and creating your own composite components is really simple. I especially like the concept of a view scope and the ability to easily attach converters and validators to GET parameters. JSF is build with extensions in mind, and lots of projects have taken advantage of that.

EJB3 is a very lightweight and easy to use technology now. Tastes may differ, but IMO EJB3 is easier to use than Spring Beans although the two are fairly equal. Spring is a bit more heavyweight as it pushes developers into maintaining huge amounts of XML. With EJB3, I basically have a POJO and only add a simple @Stateless annotation to it.

Other great things about Java EE are CDI, which can add type-safe injection and scoping to any POJO (including EJBs) and JAX-RS, which makes it really easy to support REST webservices. Oh, and don't forget bean validation and JPA.

Dude, calm down. I was

Dude, calm down. I was speaking generally (i.e. Klenex vs tissue) and did not use upper case letters (which typically means general terms). Can you run Java apps ins Tomcat and Jetty? Yup. Are they servers? Yup. I didn't say they where "Java EE Application Servers". Yes i know the diff. Should i have said Java "containers" instead? Sure. Was it worth you blowing a gasket? No.

Language is the surface of character

Uncivilzed use of language gives a lot of informations on Your character.

What is the cost of IIS?

Sure You can say that IIS is a container, but it comes WITH the operating system. The point of this post is to run your Java web applications as cost effectively as possible. Tell me. Why spend money oin WebLogic, WebSphere, or JBoss when you can architecture for availability, performance, and scalability run on Tomcat?

Another way to ask the question: If you had a start-up company for a new Web and mobile application with a Java backend, what app server would you choose?

"Sure You can say that IIS is

"Sure You can say that IIS is a container" - Because it is.
"..but it comes WITH the operating system" - And thus it is a PITA. With a Java "container" - either something provided to me, or by rolling my own - I can upgrade (or downgraded) without worrying about the OS (99% of the time). Try running a .NET webapp (or any .NET app) from usb drive.

"Why spend money..." - Who said I was spending money? I think I said I was not. FYI, you can get JBoss without spending money.

"..when you can architecture for availability, performance, and scalability run on Tomcat". I do run apps on Tomcat. And they work. But I then have to install a message queue too, if i need it.

" If you had a start-up company..." - Well, I sort of do. I am using GlassFish currently, but I am looking at JBoss. The reason i went with GlassFish (versus Tomcat) is because i need queueing and it was easier for the client to install one thing and setup as a Windows Service and the Admin console is tons better than Tomcat. Oh, I am using Tomcat too where i don't need queueing. But I think you are asking me - Would I spend money on an application server? No. Would I spend money on support? Depends.

JBoss AS 7 ?

I understand the desire to avoid WebSphere etc... but why JBoss? And what about Glassfish?

JBoss AS is free. You can pay for support if you want, but you don't have to. You can develop for it using Eclipse, NetBeans, or whatever else you want, too; there is no need to use JBoss Developer Studio.

JBoss AS 7 is looking really impressive. I was underwhelmed by the earlier JBoss releases - 5 didn't add much over Tomcat for me, and 6 was a buggy slow pig of a thing. By contrast, AS 7 has impressed me enough that I've moved my work over from Glassfish entirely.

I can see why Glassfish isn't a compelling option. It's still somewhat buggy and it's not overly fast. 3.2 looks like it'll improve things, but I've been saying that since 3.0.1.

The thing about using Tomcat is that you'll probably land up doing a lot of the integration work that's already done for you in a full container.


You make a good pint about Glassfish. It is a compelling option. My point: Why do some Java web applications even need a separate container at all? Shouldn't the Java JVM incorporate the needed functionality? For example, Microsoft applications run right on the OS.

Why not right on the OS?

Microsoft has the considerable advantage of controlling the OS and most of the stack above it. Microsoft _network_ applications do not run right on the OS, they run on top of IIS or use an embedded instance of IIS. Because MS controls IIS, the OS, .NET, and the rest they're able to integrate these transparently enough that they look like they're all part of a whole.

It'd be nice to see something similar in the Java world, but we're not going to get there in a hurry. In the mean time there are options like embedded glassfish (or Tomcat or Jetty, for that matter), where you can have your app launch a private minimal instance of the container transparently. If you use the maven embedded glassfish plugin there aren't even any code changes, though the features you have available are a bit more limited. Embedded glassfish/Tomcat/Jetty are great for testing and development and have the advantage of being easily moved to deployment on pre-installed containers if more complex features like clustering are needed down the track.

Personally, I wish people would just think about what they need before going ahead.

OTOH, there's so much marketing guff and bluster out there that making a realistic comparision of products is quite hard. Right now, you'd think JBoss AS 7 was some kind of magic that'll not only run apps fast but clean your house and take a side job to make you some extra cash. Based on what's out on the 'net you could be forgiven for thinking that Glassfish was a tiny, fast, reliable server that was easy to use and took minimal setup, too. In reality, AS 7 will be great once it's really finished, as the "Final" version is rather ... incomplete. And glassfish remains frustratingly buggy, with classloader leaks (fixed in 3.2) in trivial apps and all sorts of other fun. Similarly, from your article one could conclude that Tomcat does everything you need and the big appservers are just money-gobbling monsters.... which is true for some, but far from all, users and apps. Tomcat can be _made_ to do what you need, but it might be quicker and easier to just start with JBoss or Glassfish than end up rolling your own full-featured container on top of Tomcat.

IMO the single best thing that could happen to Java EE would be to pick the best implementation of each spec then take the others out the back and shoot them. Get everybody working in one direction. There's a horrifying amount of time and effort being wasted on all these parallel implementations of everything from JAX-RS to the servlet container to JPA. The end result is three flakey and buggy implementations coming together slowly rather than one solid implementation coming together rapidly.

"..they're able to integrate

"..they're able to integrate these transparently". Sadly, it is not that transparent. And as I pointed out, tightly coupling the container, the OS and the run time are BAD ideas - unless you are the Vendor.

Money-gobbling monsters

LOL on "money gobbling monsters". I agree with you advice to "..just think about what they need before going ahead". This an article about saving money by getting from point A to point B as fast and cheaply as possible.

I like your conclusion that "There's a horrifying amount of time and effort being wasted on all these parallel implementations..." I don't think Oracle is motivated to simplify this. If they try to they will be seen as promoting there own wares in the supposedly open Java market. If they don't do anything, the complexity continues to spin out of control.

JBoss can be free, and think about time going by

*Disclaimer* I work for JBoss, as a support engineer

1. JBoss can be free, if you want to go without paying for support.

2. As time passes, JBoss gets better and better. Eventually, WLS and WebSphere will go by the wayside as JBoss offers at least equal functionality and the benefits of crowd-inspection and rapid improvement. Proprietary solutions can't keep up. (The same is true of any lively Open Source project.) So I can't say JBoss is superior to Tomcat in this respect, but both are better than the high-dollar proprietary solutions.

3. JBoss is/will be better than Tomcat alone because JBoss is part of a middleware eco-system. Want business rules, with a web UI to author the logic? It's there. How about a feature-rich ESB to help you translate messages and proxy external service providers? Check. How about a distributed cache, super-fast messaging implementation, or standards-driven IOC framework? Check, check, and check. If any of those parts are too 'raw' (costly, in terms of developer study-time) for you to use today, then give it a year. They'll still be free and get better and more usable with every passing day. Time is on the side of a lively Open Source product. More so for a suite.

Especially with the super-fast AS7, JBoss makes a good long-term solution.



Middleware ecosystem

Rick, Great points about JBoss. You make an excellent point about the middleware ecosystem. That will be important to many enterprise clients.

With or without disclaimer -

With or without disclaimer - we should keep to the facts.

1. JBoss is not free. The General Availability releases where IMHO unuseable after 4.3.2. The confirmed more restrictive politic "GA releases are feature releases, not bugfix releases" was not this prominent in 4.x era. Add this to the terrible quality of 5.0 and 6.0 and you get a problem. Simply check JIRA open bugs in 5.0 or 5.1 that where never resolved in a 5.2, dito 6.0 - the endless discussion to get even a 6.1 or at least Patch access... No, the Source Code outside the GA releases was never really open / free. I can live with this, you have to earn money, but this spreading of misinformation is not very nice.

2. You must be kidding, I know both for years now, JBoss AS and WebLogic Server - equal functionallity? Pls Reality check? Download WLS, it's free 30 days and easy to setup. Administration, Cluster functionality, Session management, Monitoring / Overload features, Failover stuff and a gazillion more features are far far ... far beyond JBoss AS. I already said, I don't think the WLS alone is worth 5 digits fees per CPU, everyone has to decide for himselves. The problem is often, people buy WLS and don't use the buildin additional features ... thats senseless indeed.

3. Yep...suites sell the app server.

Good look with JBoss AS 7, hopefully again on the old 4.x success track. The other AS are right before you ;)


Speaking of facts . . .

. . . you should get yours straight before you claim to be an expert on them:

1. There was never a JBoss 4.3.2 release. The last JBoss 4 series GA release was 4.2.3.

2. The bug fixes for JBoss AS 5 series are in-line with our community / enterprise model as clearly described here:

3. JBoss AS 6.1.0 release target is August 12, 2011.

Hi, oh you got me...a number


oh you got me...a number permutation. You should also point out the spelling errors and language issues...look instead of luck and more.
I know the model, I rechecked your link and nothing shows that I now get a usable community edition of 5.x with patches - without 150 glaring JIRA bugs, starting with memory leaks and ending with transaction zombie files. That there will be a 6.1 is a good step (and only after long discussions, everyone can google this).

Best regards,

Not convinced

How about a feature-rich ESB to help you translate messages and proxy external service providers? Check. How about a distributed cache, super-fast messaging implementation, or standards-driven IOC framework?

All available without app server:
feature-rich ESB: Camel will be sufficient for most needs - if you want more of a full fledged ESB than use ServiceMix or Mule etc.
Distributed cache: EhCache, Hazelcast, JBoss cache ....
Standards driven IOC: Spring - the original and most common/supported IOC container available

So what is JBoss (or any other container for that matter) giving me that I can't do without?