Develop Reference

Which one is the better configuration: Tomcat only OR Apache Server + Tomcat?

I have a VPS where I want to install a web application for production.
Currently, it works on Tomcat 6 connected through Apache Server using AJP module.
Every thing works ok, but I want to know if it is a good idea to configure Tomcat as the main web server due we gonna run only JSP applications.
FYI: the server must handle https requests.
Thanks in advance.

Misinformation
Years ago there was much misinformation against using Tomcat directly as a web server, but in fact Tomcat works very well as such.
I've used nearly every version of Tomcat on various projects, though all were relatively low volume. Never let me down – well, the WebDAV module never worked right. But other than that Tomcat is fast and reliable both for static content as well as dynamic servlet work.
httpd
Apache HTTP Server ("httpd") is of course very advanced and full of features. If you need those features, then use httpd. If you have very high volume traffic, then use httpd. If you have huge amounts of static access and want to relieve Tomcat of that duty thereby letting Tomcat focus its performance on your servlets, then use httpd. If you want to keep a front-facing web site running while take Tomcat up and down, use httpd. But for most relatively simple web sites or simple web apps, Tomcat suffices.
I suggest you try Tomcat alone and see how it goes. Start with your development and testing systems. Review your config files for httpd to see if all its features can be reproduced using Tomcat features. If that all works, then do some load-testing. Either hack some load-tests of your own, or try any of the many load-test frameworks.
While you can hot-deploy webapps to Tomcat, that was not always recommended in production (I'm not sure about current versions). Plan how to handle taking down Tomcat to deploy updated apps and to perform maintenance chores.
Recent Tomcat
You say you are using Tomcat 6. You may want to consider moving to Tomcat 7 or 8, but review the release notes.
Jetty
Also consider Jetty, the most direct competitor/alternative to Tomcat. Jetty is much akin to Tomcat in its purpose, scope of features, and great reputation.

If you're using SSL you will get the following benefits by front-ending with Apache HTTPD:
Ability to specify cipher suites in order of preference, which is practically mandatory if you want case-hardened SSL, and impossible with Tomcat alone.
Ability to request or require client certificates on a per-location basis instead of globally, which is Tomcat's only mechanism.
There are many other benefits as well, such as:
the ability to load-balance between multiple Tomcat instances, which alone is probably enough of a reason to do it
more control over what's logged and where the log files go
more tools to defend against attacks of various kinds.
I used standalone Tomcats for years, but having made the switch I would never go back even for a clean-sheet project.

I don't think either is better, it depends on your requirements. In environments where you may have to address security or logging requirements horizontally across heterogeneous backends (IIS, Tomcat, etc), Apache is your friend (or an expensive load balancer).
Assuming you don't have these requirements, I don't know of any advantage in using Apache for Apache sake.
SSL is easily configured in Tomcat and performance these days is likely to be on par with Apache and can be improved with APR.

Java EE 6 Application Server for Web Profile with JavaMail

I have a Java EE web application using features from the Java EE 6 web profile + the EJB Timer service and JavaMail. I'm currently using GlassFish 3.1.2 full profile during development, but I want to investigate the alternatives because:
There seems to be a bug with multipart forms in GlassFish 3.1.2 and GlassFish 3.1.1 had other problems hurting me which are fixed in 3.1.2. (catch 22...) That bug is fixed by the jar in the ticket.
There seems to be a lot more options for application servers supporting the "web profile" than the "full profile" and the former is supposed to be so much more lightweight.
I want to choose the best option for deployment
I am currently using the embedded application server feature of GlassFish for tests, so a similar facility for any alternative is desirable. At worst, I can live with stiking to GlassFish embedded for the automated tests.
Is it possible to "add" a JavaMail and EJB Timer Service implementation module to an applicaton server implementing only the web profile? Does it work well? If this is not possible, are there alternatives to using JavaMail and the EJB Timer Service?
Which application servers meeting my requirements can you recommend?
Finally, I considered using the "Asynchronous invocation" feature of EJBs which is not part of EJB lite. If I understood correctly, it is illegal to start threads manually when running in a Java EE container. In that case, how can asynchronous operations be started in the Java EE Web Profile?
I'm still relatively new to the whole Java EE ecosystem and terminology so please don't hesitate to ask me to clarify any parts of my question.
Supporting doc
Java EE 6 web profile vs Full profile
EJB 3.1 vs EJB lite
edit 1
According to the Apache TomEE doc, TomEE, TomEE+ and OpenEJB would fit the bill.
edit 2
Based on the AS 7.1 release notes, this thead and this issue JBoss AS 7.1.0 seems to implement all the features I need.

First of all, I have never used GlassFish so I cannot give you any information about that.
I'm not sure if your application is being build for a true production envrionment but jboss 7.1 does not yet have any official commercial support in case you run into trouble.
Jboss 5.1 optimized for JDK 6 has commercial support via red hat.
That being said, a jboss instance can be fully configured and is very flexible. That means that you can start with the 'web' profile and add/remove services you do not need. (Removing unused services is always advised for production environments.)
Here is a wiki that gives information about slimming a jboss profile in jboss 5. It indicates all steps needed to remove a service.
The slimming operation can also be reversed, so you can add anything you need to a certain profile.
So there are basicly two approaches:
Start with a profile like 'default' or 'all' and start removing services that are not needed for your application
Start with the 'minimal' or 'web' profile and start adding services you are missing for your application. You copy the services from a profile that has it. (I personally prefer this approach)
Adding and removing services can be a work of trial and error though. You need to search the internet for a correct guide for the service you are trying to add or remove. (Tip, always do your operations on a copy of the profile provided by the AS and document each step. That way you can start over if you did something that seems irreversible.)
I hope this is of any help.

tom's right that JBoss AS7 doesn't have commercial support yet. However, it is coming - AS7 is being productised as EAP 6 (annoyingly!), and is going into beta in a few days. The community version has been out for a few months now, and although it does have a lot of rough edges, it basically works pretty well.
AS7 has a much more modular architecture than previous versions. The idea is that you only load the modules you need, which means that although it's a full-profile implementation (as of 7.1), if you only use web profile features, you only pay the runtime cost of a web profile implementation. You still have the bits you don't need sitting on disk, but disk is cheap (7.1.0 is 125 MB all in - hardly huge).
I'm afraid i haven't used any other fully-grown app servers (not in the last decade, at least), and so can't comment on them. I believe Geronimo supports full-profile EE6, so if you don't need commercial support, that might be worth a look.
I have spent some time using Tomcat-based setups. Yes, you can add enough extras to Tomcat to create a sort of 'bionic Tomcat' that is basically an app server, but doing it yourself is work you really shouldn't be doing - pure waste. I haven't used TomEE. I'm not a big fan of Tomcat generally, i have to admit.

As you state, OpenEJB/TomEE definitely fit the bill. Here are some examples you might like based on the things you mention:
TimerService and #Schedule
TimerService and ScheduleExpression
#Asynchronous Methods
To configure your JavaMail resource in your test case, just do like so:
Properties p = new Properties();
p.setProperty("superbizMail", "new://Resource?type=javax.mail.Session");
p.setProperty("superbizMail.mail.smtp.host", "mail.superbiz.org");
p.setProperty("superbizMail.mail.smtp.port", "25");
p.setProperty("superbizMail.mail.transport.protocol", "smtp");
p.setProperty("superbizMail.mail.smtp.auth", "true");
p.setProperty("superbizMail.mail.smtp.user", "someuser");
p.setProperty("superbizMail.password", "mypassword");
EJBContainer.createEJBContainer(p);
Then inject the JavaMail Session into your EJB via:
#Resource
private Session superbizMail;
Behind the scenes the 'superbizMail.' part is shaved off all the properties and the resulting set of properties is passed into javax.mail.Session.getDefaultInstance(Properties props). The resulting Session is what is injected into the #Resource reference

Should I upgrade JBoss or shun it completely and move to Tomcat?

I'm using a very old version of JBoss (4.2.3) and now I'm looking to upgrade (6.0). I'm using almost the full javaee stack, plus a million other things, but almost all of my jars are included in the war file itself.
Since I'm doing that do I really need JBoss? I tried plugging my existing war into the new JBoss and saw errors, but I was able to plug it into Tomcat 7 without any hassle at all. Personally Tomcat seems much simpler, more lightweight, and probably more stable so why should I not just stick with that?
If I've already fetched all the jars I need (including a few jboss jars actually) do I really need a full JBoss server? Am I making some huge mistake trying to avoid the bloat and going with just tomcat?

I'm using almost the full javaee stack
No, you're not. You're not using EJBs and JMS for a start. And I guess clustering too, otherwise this:
I was able to plug it into Tomcat 7 without any hassle at all
wouldn't work.
My take on it: if it works with Tomcat, use Tomcat. Simple things work.

It seems like you are not using EJB and stuff, as Tomcat doesn't have a EJB container, and you are fine with Tomcat.
In case you are using JBoss specific jars, I would suggest you to stick with JBoss. Or if you want to go with Tomcat, you should get rid of JBoss specific jars. BTW, what JBoss specific things you have?
[Edited after receiving more info in comments]
Hibernate would fine with Tomcat. But if you are using JBossMQ, then Tomcat may not be for you. Because Tomcat doesn't support JMS stuff. You should stick to JBoss, or if you are really looking for some simpler alternative, then I would recommend you to take a look at GlassFish. As GlassFish is a full blown JavaEE server, and offers EJB, JMS stuff. However, JBoss is widely used in the industry, as compared to GlassFish, AFAIK.
BTW, JBossMQ is replaced by JBoss Messaging in JBoss 5. And then that, JBoss Messaging, is also replaced in JBoss 6 by HornetQ. Look at this SO Thread.
If you are very much inclined towards Tomcat, then you can go with Tomcat along with ActiveMQ -- for JMS stuff. You need to configure that in your Tomcat, plus you would definitely need to change your code, if that is not very standard JMS thing. Further, do test your application thoroughly, especially JMS part, as there may be some behavioural differences.

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

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.