Spring wind is blowing, and I was wondering what would happen to a J2EE app server such as JBoss. It appears that some people find that Spring + ORM framework + alpha is a more than enough solution for small/middle size projects. Moreover, lots of companies would probably (only assumption) go for Websphere/Weblogic for a big project.
I would like to ask the authors about the future of JBoss. Do we need it nowadays, and who is going to use it ?
To be completely honest, if you're using Spring, you don't need EJBs. You can also use ActiveMQ as you JMS provider and use Jencks for Message-Driven POJOs (replacing MDBs). You could easily use these technologies in Tomcat. As long as the application scales on Tomcat (and it should), then you don't really need JBoss because you're not using EJBs or JMS.
Satou, I'll answer your questions first. You could be right that Spring will definitely take much of the marketplace away from EJB and JBoss (and the other J2EE application server vendors, for that matter).
The people who never liked EJB in the first place will just move to Spring. Many of the companies who've invested lots of money into J2EE application servers and EJB development will just move to EJB 3.0 because they don't want to re-architect.
But there will also be companies that will be happy to move to Spring because development and maintenance will be much less expensive.
Joshua, I don't think EJB 3.0 will decrease the interest in Spring. EJB 3.0 took most of its ideas for simplification from Spring and Hibernate.
Even though I like EJB 3.0, I'm still moving to Spring because: 1) Spring's IoC is much more flexible and easier to use than EJB 3 Dependency Injection.
2) Spring has great API wrappers for JDBC, JNDI, JMS, Hibernate, and Class Loading.
3) Spring has a good Exception Handling strategy, and EJB/J2EE doesn't.
4) You can't test Stateless Session Beans outside the container, but you can test Spring Beans outside the container.
5) Spring/Hibernate is enterprise-class because of its support for CMT transactions and connection-pooling.
6) If you need JMS and an asynchronous JMS listener, you still don't need EJBs or a full J2EE container. You can use ActiveMQ as your JMS provider, and Jencks provides Message-Driven POJOs (an MDB substitute).
7) Spring is still simpler to deploy - you only need a WAR. If you have a web app that uses EJBs, then you still need an EAR that contains a WAR and an EJB JAR.
So with Spring, you have all the above benefits and no real drawbacks, plus you can run your code inside or outside the container. For test and production, you could run Spring inside of Tomcat, which has a much lighter weight footprint than a full-blown J2EE application server.
That's excellent information. It's so hard to tell which technologies to use with Java on the server-side these days. There are 5 billion web frameworks out there with more announced daily and what's worse is that each of the tools Eclipse/Creator/Netbeans/JDeveloper make a lot of assumptions about you buying into their way of approaching the problem.
If you don't mind me following up on my question a bit...
If you were to pick your best basket of tools, frameworks and technogies for building a server side app that was fairly robust, but maybe not on the scale of a banking application, what would you pick? JSF? Struts? Spring? Eclipse? Creator? Hibernate? EJB? Tapestry? Tiles? Ant? Maven? JDO? HttpUnit? Etc?
Picture this: They just dropped a development machine, a test server and a deployment server on your desk. What would you want them loaded with?