Re: Java EE on tomcat?
On 9/8/2011 2:22 PM, Lew wrote:
On Thursday, September 8, 2011 10:53:18 AM UTC-7, nroberts wrote:
If higher ups decided that I had to work with Tomcat...no JBoss or
glassfish or anything...what limitations am I looking at? What parts
of Java EE become unavailable to me?
Who are these "higher ups" and what makes them think they're
qualified to make technology decisions?
Most likely more qualified than OP.
That said, most systems run better on Tomcat, or better yet on Apache
Web Server + Tomcat, anyway. EJBs are a pain in the butt most of the
time, and queues have specialized use cases you might not even have.
Unless one is allergic to XML config files and/or annotations, then
EJB's should not really bother anyone.
Configuration differs. Most application servers like JBoss and
Glassfish work through their own management consoles (web apps in
their own right). With Tomcat you configure your DBMS connections
through the server.xml and web.xml files. The Tomcat docs explain it
well.
JBoss connection pools are defined in deployable files.
What are the decision factors in the choice between Tomcat and a more
robust app server? Even if you aren't the decision maker you should
have insight into the balance sheet in that choice. If they make a
bad decision and you haven't done your fiduciary duty, then it's
*your* fault.
Whichever way you go, push for the latest stable version of the app
server or Tomcat, and for Java 6 or 7 as the base language. Push
hard. There's no valid reason to go with Java 5 or J2EE in the
platform, given backward compatibility and the absence of license
fees. Only development and maintenance costs should weigh into that
decision, and use of outdated and obsolete tools affects those rather
severely.
In this case where thy have decided to switch from JBoss to Tomcat
the only sensible thing is to pick a new Tomcat and a new Java.
But there are good reasons why stuff sometimes stay on old stuff - it
can be very costly to lift the app and do a full retest.
Future decreases in development cost is a soft argument. It sounds good,
but I doubt that many teams would commit to a significant reduction in
hours/task-size due to a platform lift.
Arne