Spring vs Jboss

Question

What are the advantages and disadvantages for Spring vs. Jboss for an enterprise web application.

Answer 1

This is a good question. Some have incorrectly stated here that this is an apples to oranges comparison, i.e. Jboss is a container, and Spring is simply a framework, like Struts. However, the reason this is a bit confusing is that both JBoss and Spring have expanded considerably from their original, simple origins, and are thus moving closer towards each other. One easy way to understand JBoss is that the name was original "EJBoss", and it was intended on being an open-source J2EE application server, so it had the advantage over tomcat over serving as an EJB container, and thus could compete with WebSphere and other proprietary application servers.

And Spring was an IoC framework (now referred to as "Dependency Injection"), essentially a factory for objects so that you can follow a more "loosely coupled" design.

However, with their popularity, both products expanded. For example, JBoss now has it's own IoC container: JBoss IoC

JBoss provides its own lightweight IoC container called: JBoss Microcontainer. JBoss Microcontainer is a lightweight, Inversion of Control/Dependency Injection container similar in concept to Spring, Pico Container, and Plexus.

And while Spring can run perfectly well, coexisting (mostly) happily with JBoss, it doesn't need a full-blown EJB container, it can run easily in tomcat. The whole design goal of Spring was based on the idea of lightweight design, and the use of POJOs, and the lack of requirement for a heavy-weight container, which was very contrary to EJBs, and thus would seem at odds with JBoss.

Rod Johnson has pointed out that there's no reason you can't run Spring in JBoss:

Spring is designed to work in any application server (or outside an application server); using Spring does not mean ignoring what the server may have to offer. It just provides greater choice in a lot of cases.

So what you have to decide is what parts of the two systems you want to use, and what Java standards you want to adhere to. According to this article, on JBoss and Spring, which covers how well they adhere to standards, it does seem, depending on which technology you select, you are picking a side, as this seems to be a pretty contentious battle.

What comes next is anything but detente, as JBoss and Spring Source battle over everything from XML to integration to tools to eventually virtualization, itself....its a healthy competition,

[snip]

Only time will tell, but i think that this battle only makes things better for developers, more choices rather than .Net, and more innovation around Java, it will be a tough test for JBoss, but one that they can handle if execution is flawless, otherwise, look for Spring Source to drive a wedge between perceived and real advantages of JEE 6...sooner, rather than later, portability of applications will have to be demonstrated in order to counter the proprietary models, and that has not happened,

For a more up-to-date look at adherence to the various Java standards, take a look the request for feedback on Spring 5. You can get an idea of the constraints the Spring designers face, while also highlighting the fact that, for the Spring market, it is important to ensure Spring supports the various EE servers:

We intend to softly upgrade the EE baseline as well. Now, this is a bit tricky since we effectively have individual requirements here - and we need to consider the enterprise adoption levels in production environments:

We’ll definitely raise to Servlet 3.0+ (from our present Servlet 2.5 runtime compatibility) but no higher since we’d like Spring 5 applications to run on EE 6 baselined servers still. See my previous blog post for a discussion on why this is unavoidable, given the market situation with Java EE 7 and the multitude of servers which is still based on the Servlet 3.0 API. [snip] It’s just a shame that we have to keep supporting the 2002-era JMS 1.1 API… We’d like to raise to JPA 2.1+ and Bean Validation 1.1+ but our hands seem to be tied: TomEE 1.7 and JBoss EAP 6.4 have hard JPA 2.0 and Bean Validation 1.0 APIs in them, and WebLogic 12.1.3 has JPA 2.1 but no Bean Validation 1.1 API (despite them being related).