Spring vs Jboss

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: JBossMicrocontainer. JBoss Microcontainer is a lightweight, Inversion ofControl/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 anapplication server); using Spring does not mean ignoring what theserver may have to offer. It just provides greater choice in a lot ofcases.

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 Sourcebattle over everything from XML to integration to tools to eventuallyvirtualization, itself....its a healthy competition,

[snip]

Only time will tell, but i think that this battle only makes thingsbetter for developers, more choices rather than .Net, and moreinnovation around Java, it will be a tough test for JBoss, but onethat they can handle if execution is flawless, otherwise, look forSpring Source to drive a wedge between perceived and real advantagesof JEE 6...sooner, rather than later, portability of applications willhave 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 abit tricky since we effectively have individual requirements here -and we need to consider the enterprise adoption levels in productionenvironments:

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

As already said, but let me just restate the point. JBoss is an application server. Some Java application servers include

• Websphere
• Glassfish
• JBoss

Spring is a framework. A rather large framework which offers quite a bit but for me one of the main features is MVC. MVC is a design pattern where you separate your Model from View from your Contoller. The model is the representation of the data. This can be backed by things like database or XML files. The view is what is used to view the model. This can be either web frontend or a windows application. The user will interact with the view. The user will express their desire for the model to be updated. This is where the controller comes in. We use the contoller to tell the model to update. And because the view is based on the model the view then gets updated too. This is over simplifying but in a nutshell. Other MVC framework that you can look at is Struts.

Like I said earlier there are other features that Spring offers such as

• Security framework
• Inversion Of Control
• Dependency Injection

Here's my opinion:

Spring represents all that is good in Java EE, whereas JBoss represents all that is bad.

Well... that didn't go over so well (not that I thought it would). I'm just saying that I would never choose JBoss to host any application. It's just so clunky and heavyweight, and does not do anything particularly well. I like Spring because it feels less monolithic and clunky. Granted, Spring is not an application container, but it can be used to build up most of the infrastructure you need to host an app - you just have to plug it into a container, and Spring handles the rest.