Develop Reference

Jboss or Tomcat

I'm working in an infrastructure team(Jboss 4.02/Tomcat 5.5/Weblogic 8.1 servers)in my company...some of the weblogic java applications are moving to jboss/tomcat servers.So what are the criterias we need to consider whether we need to go for jboss or tomcat? which is the best option?
Thanks in Advance,
Rakhesh

The main difference is certainly the fact that JBoss is an application server and supports the full Java EE stack, while Tomcat is a servlet engine and supports only a small fraction of the APIs which are defined in Java EE.
So, your main criteria should be: Which APIs (Frontend, Business Logic, Persistence, Third-Party, ...) do you need?
You should not make this an easy decision. The fact that you are asking the question indicates that you probably did not have the chance to play around with both and familiarize yourself with the concepts behind Java Enterprise stacks (Java EE vs. Spring vs. DIY).
My advice would be to take the time to evaluate both system - it looks like you are able to use both.
If you don't need much, you're probably better off with Tomcat, which is small and easy to use, but can be a nightmare to configure if you need advanced functionality.
JBoss AS comes with a full and mature stack. Everything is just right in place and works fine - the price you'll have to pay is that it way bigger and will take longer to start / stop / redeploy.
But again: That's a serious decision with a high impact on pretty much everything...

Both Tomcat and JBoss are very easy to install - simply unzip a file, and start it with a script. Both Tomcat and JBoss have great support for products like IDE's, monitoring tools, and such.
But in your migration case, JBoss is a better choice. Chances are your Web apps need JNDI data sources and JTA transactions - these things come built in to JBoss 4+, whereas you would have to graft them on to Tomcat 5.x, with much effort. You old WAR's will find JTA and JNDI data sources with no trouble on JBoss. Tomcat can indeed add these features, but JBoss packages them nicely into the system nicely. So even if you have no EJBs or JMS, then JBoss is still a good choice because many apps do need JTA and JNDI.
But of course if you find EAR files for your apps, then Tomcat will not work. And then JBoss will deploy the EAR files nicely.

JBOSS uses Tomcat as its servlet/JSP engine, so it's JBOSS and Tomcat or WebLogic.
The answer depends on whether the original apps use EJBs or JMS services. If they do, you have to use JBOSS, because Tomcat doesn't support EJBs (unless you add OpenEJB) or JMS (unless you add something like RabbitMQ or OpenJMS).
If you don't use EJBs, and only have JSPs, JNDI data sources, and JDBC, then you can deploy your apps as WAR files on Tomcat and pass on the full Java EE stack altogether.

I think you should consider starting with different input data:
what are the applications requirements ?
what are the production constraints ?
which product suits well to the administration team?
Just write a matrix with the 2 products and those criteria and your choice will be done!!!
Jboss is far more heavy than Tomcat but could offer some value added while putting the application in place ? Do you have some Nagios/Tivoli or any other SNMP management infrastructure ? in this case you can finnd easily SNMP adaptors providing proprietray MIBs to manage your JBoss server...JMX Beans in old releases are a very conveniant way to administer such tool
HTH
Jerome

Jetty 8 + EJB 3.1 + JTA + CDI + JPA 2 stack?

Can anyone tell me if it is currently possible to "glue together" a partial Java EE 6 Web Profile over Jetty?
I've found a lot of articles about integrating standalone EJB 3 containers, JTA providers, etc with older Jetty versions, so I wounder if I could make it all work together.
I would like to assemble a Servlet 3.0 + CDI + EJB 3.1 + JTA (if needed, all I really want is declarative transaction management) + JPA 2 environment over Jetty 8 (or Tomcat 7 if no Jetty alternatives are available).
My questions are: Can it be done? Has anyone managed to do that? Any articles about getting OpenEJB, Atomikos, Weld, EclipseLink and Jetty (or any other similar stack) working together? Any magical "do it all" pom.xml files out there?
PS: Yeah, I know I could just use GlassFish (which I like very much). I'm just wondering about how hard would it be to get something similar working with a Servlet Container, and how the two environments would compare in terms of complexity, performance, size, deploying speed, hardware resource consumption, etc.

I'd describe this as still in the early stages, but here is what we have so far:
http://svn.apache.org/repos/asf/openejb/trunk/openejb3/assembly/openejb-jetty/
Note, Apache TomEE lives at a similar path, i.e. 'assembly/openejb-tomcat'. Plan is to call the Jetty version Apache JetSet and have it be fully embeddable. Most people with commit are currently working on getting Apache TomEE to be officially Java EE 6 Web Profile certified. I'd describe that work to be in the late stages. We've a great setup in Amazon EC2 to run the web profile TCK against TomEE using a hundred EC2 t1.micro spot instances. It's pretty sweet. The TCK agreement with Apache and Oracle does not allow us to share access publicly. However, any Apache committer can sign an NDA to get access.
Ok, so I mention all that about TomEE because the plan is once we're done with the Tomcat version, to do it all over again with Jetty (JetSet). Many of us committers, myself and Jonathan Gallimore for example, actually prefer Jetty by a large margin. But as the Tomcat integration code was much further along and had more users, we decided to just finish that one first. There is an incredible amount of work that isn't Tomcat specific that we will be able to leverage in the Jetty version; getting access to the TCK legally, the heaps of code to get it to run, the more heaps of code to get it automated, and numerous integration bits which are generic and not specific to Tomcat.
All that said, there's no reason others have to wait to work on a Jetty version just because most of us are still finishing the Tomcat version. Apache projects should be viewed as individuals working together, not companies like Oracle or Redhat or VMWare. That can be both good and bad. The good part is that if you or anyone else wants to hack on the Jetty version you can do that right now. You'll have to submit patches for awhile till you earn commit, but having someone else do the actual commit command is not that bad. If you start small and stay active and open, it's usually pretty easy to earn commit. The key to getting patches in quickly is a steady stream of small to moderately sized patches. Any step forward or sideways with no steps backward is a good patch in my opinion. As long as people can see where you're going it's good enough. Certainly more Agile than the one-big-patch approach and allows for all the really fun and collaborative magic to happen along the way.
Some threads which would be good places to say hello. Step 1 is just to say hello. No need to have code in hand to talk on the dev list or be taken seriously:
http://openejb.979440.n4.nabble.com/Jetty-Integration-td1457408.html
http://openejb.979440.n4.nabble.com/Jetty-Integration-td2318962.html

Tomcat has that stack implemented in a server called TomEE(formerly TomTom).
These are the components it uses.
Connector Apache Geronimo Connector
CDI Apache OpenWebBeans
EJB Apache OpenEJB
Javamail Apache Geronimo JavaMail
JPA Apache OpenJPA
JSF Apache MyFaces
JSP Apache Tomcat
JSTL Apache Tomcat
JTA Apache Geronimo Transaction
Servlet Apache Tomcat
As far as Jetty I'm not sure. OpenEJB is your only option for EJB outside of a JavaEE6 container(AFAIK) and I'm not sure Jetty is 100% tested with this. For CDI you can always use something like Seam.
In my opinion I believe the Spring framework would be your best option for the Jetty container(that's just my opinion though). In my experience after trying to get Tomcat working with Open EJB, Spring is a lot easier to set up.
You also have to remember Open EJB doesn't implement the entire EJB 3.1 stack at this point.
Also Open EJB is not tested on Tomcat 7 either. So you have to stay with Tomcat 6 if you go that route.

OpenEjb has not released a version with JPA2 support, although their development version supports JPA2 fine AFAIK.
I'm using embedded OpenEjb in Jetty6, because I could not get my app working in newer jetties yet. I think there is work under way to get an OpenEJB tightly integrated with Jetty like TomEE, but that may be some way off..

Geronimo is a complete J2EE stack which runs on top of Jetty.
There's a document on its setup on https://cwiki.apache.org/GMOxDOC30/configuring-virtual-host-in-jetty.html

Why is Jboss "better" than Tomcat? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm currently starting a new app development. The app architect insists we use JBoss5 because its "better". Do anyone has a wider definition of "better" (if its the case)?
I have experience using Tomcat5 and 6 in large scale applications with big user loads and it handles pretty well (IMHO). Both would be running over a RedHat6 in identical hardware conditions (in case the implementation matters).
Thanks in advance

To say that any tool or framework is just 'better' is ridiculous. It always depends on the situation, architecture, etc. You don't necessarily want to use a hammer to drive a screw.
I wrote JBoss in Action, so I obviously like the JBoss technology, but I'll be the first to say that JBoss can be overkill in many situations. For example, for the last two sites I've developed, it made more sense to build with Grails and deploy on a standalone Tomcat instance.
Its a bit unfair to say that all you get when using JBoss is EJB and JMS. JBoss offers many services and features, including:
Servlet/JSP container
JNDI
EJB
JTA
clustering
caching
JMS
Datasource / Resource management
JMX integration
OSGi support
web services
portals
Web Beans (Seam)
Some administrative consoles
an IoC container
etc.
The thing that attracts many architects to JBoss is its flexibility. It uses a plugin architecture that allows you to add and remove services. As other have said, in uses Tomcat as its Servlet container, so you can literally whittle JBoss down to where it is practically just a Tomcat server. What is the benefit of doing this? Future proofing if you think that you're going to utilize other features of JBoss.
These services in JBoss come pre-integrated and strive to provide a consistent deployment model that minimizes your effort in writing application logic or configuration to integrate them yourself. That being said, other frameworks like Spring also do a great job of supporting a uniform ways of integrating many popular libraries and frameworks. But since they focus on integrating 3rd party libraries, the interoperability between services is up to you. Because JBoss is building the services and the integration platform, they spend time developing (and providing support) for interoperability.
Some questions to ask when making a choice are:
Are you going to use standard JavaEE architectural components like EJB?
BTW, EJB can be run in standalone Tomcat using the JBoss embedded container, so if EJB is all you're using, then you still don't have to use JBoss
Are you going to utilize Web Services, Portals, JMS?
Are you looking into building with Web Beans or Seam?
What deployment platforms (Tomcat, JBoss, etc) does your IT, support, and development staff currently use? If you are going to use something new, you will incur additional cost to learn the new platform.
If you're selling a product that customers will deploy, what impact will it have on the customers' IT organization.
Are you going to need paid support?
You can find support for Tomcat through many companies (including Red Hat I believe).
You'll need to compare the costs, because I don't think JBoss support is cheap, though I haven't looked up prices lately.
Will you need to do any sophisticated clustering?
JBoss has some wonderful clustering capabilities, and you'll probably get good clustering support through Red Hat. Though, for full disclosure, I've never done any complex clustering with any other frameworks to be able to compare.
Are you going to need advanced transaction management (distributed transactions, 2-phase commits, etc)
Not to sound like a shameless plug, but the first chapter of JBoss in Action is available for free on the Manning website. Though we don't do a direct comparison between JBoss and other applications servers and deployment environments in the chapter, we do talk about the architectural differences a bit, which is relevant to your question.

I'm currently starting a new app
development. The app architect insists
we use JBoss5 because it's "better". Do
anyone has a wider definition of
"better" (if its the case)?
Funny, because JBOSS uses Tomcat as its servlet/JSP engine.
Sounds like "better" means "supports EJBs and JMS", because Tomcat out of the box has neither.
But that's not an issue if your application doesn't use EJBs or JMS.
And if you do need them, you can add them to Tomcat with OpenEJB and RabbitMQ or ActiveMQ.
I'd ask your app arch when the last time they wrote something besides Power Point slides or UML documents. The response might surprise you.

JBoss is an Application Server while Tomcat is a Servlet container
So JBoss may be better than Tomcat in the sense it contains it, plus other components. That's it.
If you're not going to use those other components, you're wasting resources. If you need those other components then Tomcat is not enough.
It depends, probably your Architect has something else in mind.
I wonder what would he say if you ask him directly?

It's not better, it's just more. JBoss includes Tomcat.

As #duffymo points out, JBoss uses Tomcat for its web container so better makes not much sense if we compare equivalent things (i.e. Tomcat and the web container part of JBoss). And if you are not going to use JTA, EJBs, JMS, JMX, etc, there is no real advantage at using JBoss, especially during development (Tomcat is lighter and starts faster, this is often appreciated by development teams).
There are some cases where you could prefer JBoss for production though (I'm still assuming you're not using EJBs, etc):
The production team is trained or used to use JBoss in production, tools (deployment, monitoring, etc) are tailored for JBoss.
The company has a support contract for JBoss (although you can also get support for Tomcat).
But I'm not sure this is what the app architect meant. I would try to discuss this choice with the architect, maybe he has a rationale explanation. And if really JBoss has to be used in production, you can always use Tomcat or Jetty during development.

If you use JBoss, you can pay Jboss.org for support. But it is not the case with Tomcat.
This is true, however RedHat (who bought out Jboss.org) will require you to change to one of their supported versions of JBoss

JBoss is J2EE specification compliant, it supports J2EE specification very well, such as EJB, JTA,JMS, JNDI and etc. Tomcat is only a servlet container, although it also supports a bit J2ee specification. When you want to use J2EE component, you should consider JBoss first.
Forgot a point, JBoss supports JMX very well, especially in version 4.*. I have experienced a project, it doesn't have a web UI, JBoss is used just as a platform and EJB container to integrate all the standalone application on it use MBean.

What are benefits of JBoss AS-based application architecture?

I am trying to understand what does JBoss AS can bring into the project, comparing to standalone architecture?
My model application is a solid thing, starting, running and stopping as a whole and solely at the host.
It has a database storage, and communicates to user and other servers, clustering required.
It has web-part. It's just a standard big application.
JBoss for me is a shell for (in general) multiple applications, providing my application with some standard services. This shell is also a solid thing - "get all or nothing", something can be turned on/off (influencing your app unpredictably, or influencing other part of the JBoss) or replaced (very hard and is already kind a hack) with different version or other module.
Standalone application for me is something combined of pieces with glue among them (Spring if you like) with IoC wiring. We can get everything we could have with JBoss, but separately. Spring or other glue serves here like an application server, but it's thinner and we still can replace parts or even Spring itself (IoC wiring is straightforward from coding point of view).
For me, standalone, AS-free approach gives more control and flexibility. And further more, last versions of JBoss AS are purely documented, some features (most interested) are not documented at all.
So, why somebody still choose JBoss - what are benefits?
I favors more standalone application approach, but need more facts to understand better and convince others.

It seems to me that what you are describing is the classic choice between best-of-breed (collecting all the parts and glueing them together your self) versus integrated stack (JBoss wrote all the parts and integrated them for you). This is a debate that will rage on for eternity. If best-of-breed is working for you then stick with it.
JBoss is a J2EE container. Take a look at the J2EE spec if you are unfamiliar with it. Basically Sun's community process came up with an development framework that contains components that you may be interested in when creating large scale apps. J2EE contains multiple sub specs such as Servlets, EJB, JTA, JMS, and a whole host of other alphabet soup technologies. If you aren't using any of these technologies then you do not need a J2EE container. If you are just interested in using Servlets and JSPs then you are better off using a servlet container such as Tomcat, Jetty, Resin, etc.
Providing enterprise features such as scalability, transactional support, federated user management, etc. are difficult. A J2EE container provides a standard level of these features. If you can find them elsewhere to a level that meets your satisfaction then more power to you.

You can also pick and choose if you are running inside JBoss. If you are happy with the JBoss services you can use them or deploy some others if you don't like the one JBoss provides for you.
Starting from the JBoss minimal configuration and building up your own configuration should give you a setup where you don't have services running that you don't need. Personally, I like to know what my AS is running, so I prefer to start from minimal configuration adding only the necessary parts.

I would say the only reason to use JBoss is if you need to access the Java EE services (like Messaging, container-managed transactions and similar).
Keep in mind JBoss is (roughly described) Tomcat plus Java EE services (yes, yes, I know, this is a very simplified approach, just bear with me). I mention this as I would say your decision is:
If you only need IoC and some other capabilites you can get with Spring and Tomcat, go with that
If you application requires Java EE services, use JBoss
Keep in mind you can always start with the basic system (Spring + Tomcat) and move to JBoss if required later on. Nothing forbids that.And probably starting with that approach will show you if you really need the Java EE services or you were over-engineering the solution.

Which web containers install themselves well as a Windows service?

We have had a web application product for several years, and used Tomcat to deploy it under Windows as it registers itself as a Windows service so it starts and stops automatically.
We may now happen to need more Java EE facilities than is provided by Tomcat (we are very tempted by the Java EE 6 things in the container) so the question is which Open Source Java EE containers work well as Windows services. Since Glassfish is the only Java EE 6 implementation right now, it would be nice if it works well, but I'd like to hear experiences and not just what I can read from brochures. If not, what else do people use?
EDIT: This goes for web containers too, and not just Java EE containers. We will probably keep the necessary stack included until we find the right container and it gets Java EE 6 support.
EDIT: I want this to work as distributed. I'm not interested in manually hacking wrappers etc., but want the installation process to handle the creation and removal of the service.
EDIT 2012: It turned out that the Windows installer for Glassfish can install as a service (requires .NET). Component web site http://kenai.com/projects/winsw. Has proven very robust.

We use Tomcat as a service. We have also used JBoss as a service.
It is possible to run GlassFish as a service.
It is also worth noting that most of the commercial Java EE containers can also run as a service. In particular, I know that all of the following can be run as a service, since we have set them up in that way:
Netweaver
WebLogic
WebSphere
In fact I think you would be hard pressed to find a Java EE container that could not be run as a service, since you could always use the Java service wrapper to wrap any java program as a service.
Since it was mentioned in another answer that you might also be interested in web servers running as services, it is probably worth pointing out that the big two on Windows, IIS and Apache, can both be run as services.
Edit: Since you edited to ask specifically about Java EE containers that contain installers that install the windows service:
Tomcat
JBoss
Netweaver
WebLogic
WebSphere
There are probably others, but these are the only ones that I have used.

There is Platform Services Support in GlassFish v3 which can interact with Solaris/OpenSolaris SMF and Windows Services. To my knowledge, it just works.

I use Caucho's Resin under windows, it comes with its own service installer which works quite well for me.

We use JBoss and it runs perfect as a service, no problems so far. We even have loaded the servers with ssh acces so we can remotely restart the services if we want.

I've used Glassfish (Version 2 though) as a Windows service. While it does take some work to get things installed, once set up, it worked pretty well. We used it in a production environment, and our set up consisted of a two node cluster (so we had to set up a domain, and two nodes (on two different machines)).
If I recall correctly, my biggest challenge was trying to use sc, and figuring out its funky escape sequences.
Another thing to look at is Hudson. I've always been impressed with how it installs itself as a Windows service. You may want to have a look at how they do it. They use Winstone as their embded servlet engine though, which as far as I know, is not EE 6 compliant.