At present we deploy to JBoss 4.2 as this is the application server deployed on our cluster. The application currently only makes use of JBoss's connection pool handling through JNDI and the JBossWeb's embedded Tomcat and a couple of JBoss' Tomcat valves (specifically RewriteValve, nothing too difficult to do ourselves).
JBoss seems like overkill to me, should we switch to straight Tomcat or are there any advantages to staying with JBoss? Does Tomcat integrate any better with Eclipse?
If you aren't using any of the advanced features of JBoss and you aren't planning to, then it's probably better to go with a pure embedded Tomcat. This way, if a security fix is found in Tomcat, you can upgrade just the one single embedded component and move on. JBoss is significantly larger and is thus more difficult to upgrade.
If all you are using from JBoss is JMS or JNDI or something else that is easily embeddable as a separate 3rd party component in Tomcat, then by all means drop JBoss and move to just an embedded Tomcat.
When should you stick with JBoss? When using JBoss makes your life so much easier that the extra work of upgrading JBoss is worth the effort. This is true for many people. It sounds like it is not true in your case.
As far as integrating better with Eclipse, I expect that both integrate pretty well with Eclipse. I use MyEclipse, which supports both JBoss and Tomcat. So this may depend on what version of Eclipse and what plugins you are using.
What sort of integration with Eclipse are you after? I believe there are plugins which will do some sort of integration (such as the Sysdeo Eclipse Tomcat Launcher plugin), but I always found it easiest to just start up Tomcat in debug mode if I needed to - and that was pretty easy.
As for whether it's worth sticking with JBoss: if you don't need the functionality, it's probably not worth it. There are plenty of ways of doing connection pooling within Tomcat, depending on what else you use. (For instance, if you use Hibernate and Spring, various connection pools work well within that.)
Tomcat provides its own JNDI implementation anyway though - as per the Tomcat 5.5 docs.
There's a lot to be said for having a reasonably "lean and mean" stack - not in terms of performance, but in terms of understanding what's happening within the app, and simplifying deployment.
Depending upon what you're trying to do exactly, you might also consider Jetty.
I'd go with Tomcat or Jetty if you only need JMS, and if you don't need an app-server managed transaction provider for transactions that span more than just JDBC (for example a transaction that spans JMS + JDBC).
While you can do JTA and JMS outside of an application server like JBoss, I've had very mixed experiences trying to get JTA to span JMS and JDBC under Tomcat. Maybe it was an early release of ActiveMQ, but it really ate up multiple months in a very important project. There is something to be said for the infrastructure that a J2EE server like JBoss provides, esp. when you do need JTA with XADataSources. Trying to recreate that with stand-alone components is confusing.
BTW, I'd consider Jetty over Tomcat if you have a choice.
As far as Tomcat and Eclipse integration, there are many options here. I use a (somewhat custom) plugin call Sysdeo Tomcat Plugin for Eclipse. The standard approach is to use something like WTP. I use the Sysdeo Tomcat plugin because it seems to have the lowest overhead. Another option is to just use the Jetty Eclipse plugin - again, I've found Jetty to be preferable to Tomcat in almost every way possible.
Hi,
You could try this: http://www.atomikos.com/Publications/J2eeWithoutApplicationServer - combined with a ligh-weight web container and Wicket if you need a web tier.
The combination of these will give you unprecedented productivity in Java/JEE.
HTH Guy