Re: Java EE on tomcat?
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?
Some of the management console stuff goes away, queues go away, EJBs by def=
ault go away but you can add them back with Apache OpenEJB. Why you'd want=
to, though, that's another question.
Who are these "higher ups" and what makes them think they're qualified to m=
ake technology decisions?
That said, most systems run better on Tomcat, or better yet on Apache Web S=
erver + Tomcat, anyway. EJBs are a pain in the butt most of the time, and =
queues have specialized use cases you might not even have. For the stuff y=
ou most likely care about, namely web pages, Expression Language (EL) the J=
ava Persistence API (JPA), and JSF/XHTML, Tomcat is eminently suitable.
Configuration differs. Most application servers like JBoss and Glassfish w=
ork through their own management consoles (web apps in their own right). W=
ith Tomcat you configure your DBMS connections through the server.xml and w=
eb.xml files. The Tomcat docs explain it well.
Have you studied the Tomcat docs yet? You should.
What are the decision factors in the choice between Tomcat and a more robus=
t app server? Even if you aren't the decision maker you should have insigh=
t into the balance sheet in that choice. If they make a bad decision and y=
ou 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 n=
o valid reason to go with Java 5 or J2EE in the platform, given backward co=
mpatibility and the absence of license fees. Only development and maintena=
nce costs should weigh into that decision, and use of outdated and obsolete=
tools affects those rather severely.
--
Lew