Spring vs Jboss
JBoss is a container, spring is what runs inside the container. You are comparing apples to oranges.
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.
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
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).