Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Java EE on tomcat?

Reply
Thread Tools

Java EE on tomcat?

 
 
nroberts
Guest
Posts: n/a
 
      09-08-2011
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?
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      09-08-2011
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 default go away but you can add them back with Apache OpenEJB. Why you'd wantto, though, that's another question.

Who are these "higher ups" and what makes them think they're qualified to make technology decisions?

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. For the stuff you most likely care about, namely web pages, Expression Language (EL) the Java Persistence API (JPA), and JSF/XHTML, Tomcat is eminently suitable.

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.

Have you studied the Tomcat docs yet? You should.

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 obsoletetools affects those rather severely.

--
Lew
 
Reply With Quote
 
 
 
 
nroberts
Guest
Posts: n/a
 
      09-08-2011
On Sep 8, 11:22*am, Lew <(E-Mail Removed)> 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?

>
> Some of the management console stuff goes away, queues go away, EJBs by default 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 tomake technology decisions?


Dunno. People with more seniority, experience and authority than I
have at the moment. I'm just trying to gage how much I should fight
this or whether using Tomcat would be quite reasonable. Right now I'm
thinking that most of the complexity of the current code base is
caused by J2EE requiring a lot of "upkeep" crap and that simply
migrating to the current EE standards, along with some fairly straight
forward refactors, would mitigate most architectural "issues".

>
> That said, most systems run better on Tomcat, or better yet on Apache WebServer + 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 you most likely care about, namely web pages, Expression Language (EL)the Java Persistence API (JPA), and JSF/XHTML, Tomcat is eminently suitable.


I'm completely new to Java but in reading tutorials and such I'd
imagine writing Java web applications without EJB, especially the
current standard, would just add a bunch of work. What about EJB
makes it a pita?

> 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 decisionand you haven't done your fiduciary duty, then it's *your* fault.


Yeah, I'm trying to look into that. As the new guy and one who has 0
experience with Java technologies less than a decade old, it's going
to be hard to get input I think. I've asked what the guiding concerns
are though.

What could those concerns be? The program I'll be writing is
basically this thing that imports data into a database, does some
manipulations and comparisons, and outputs a "report" in a particular
command language. Various aspects of its use need to be limited by
access, pay-grade, responsibility...etc... Based on my limited
understanding, what exists now doesn't need to be THAT secure, but
what they may want to do later would need a great deal of security.
Is it reasonable to write such a thing with the parts of EE possible
to use with tomcat?

>
> 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.


One thing I've pushed on is trying to upgrade our JBOSS server to the
current version (we're currently stuck on 4.0). I don't really know
what's going to be required to do this, how much work, etc...but I
felt it worth looking into. Just got a push-back hard, from multiple
directions, saying that we're rewriting the whole thing to only use
tomcat anyway.
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      09-08-2011
On 9/8/2011 10:53 AM, 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?



You might want to ask "What parts of JEE do the powers-that-be want?" I
might interpret a requirement to use Tomcat as a demand to just use the
servlet spec and drop the rest of it.

Best to ask and be sure.

 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      09-08-2011
On 9/8/2011 1:53 PM, 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?


Tomcat is a web container only (Java EE Web Profile in
Java EE 6 terminology).

That means that you have servlet, JSP, JSTL, EL, JSF etc.
to work with.

You don't have EJB, JCA, JTA, JMS etc..

You can also use all the third party web frameworks (Struts 1,
Wicket, Spring MVC etc.).

Most likely you will be fine, but obvious you should narrow
what you study to match what you have.

Arne

 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      09-08-2011
On 9/8/2011 3:08 PM, nroberts wrote:
> On Sep 8, 11:22 am, Lew<(E-Mail Removed)> wrote:


>> 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. For the stuff you most likely care about, namely
>> web pages, Expression Language (EL) the Java Persistence API (JPA),
>> and JSF/XHTML, Tomcat is eminently suitable.

>
> I'm completely new to Java but in reading tutorials and such I'd
> imagine writing Java web applications without EJB, especially the
> current standard, would just add a bunch of work.


If the app you will be developing does not require any of the stuff
you are missing, then it will not have any impact at all.

That is not an unlikely scenario.

> What could those concerns be? The program I'll be writing is
> basically this thing that imports data into a database, does some
> manipulations and comparisons, and outputs a "report" in a particular
> command language. Various aspects of its use need to be limited by
> access, pay-grade, responsibility...etc... Based on my limited
> understanding, what exists now doesn't need to be THAT secure, but
> what they may want to do later would need a great deal of security.
> Is it reasonable to write such a thing with the parts of EE possible
> to use with tomcat?


Yes.

>> 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.


> One thing I've pushed on is trying to upgrade our JBOSS server to the
> current version (we're currently stuck on 4.0). I don't really know
> what's going to be required to do this, how much work, etc...but I
> felt it worth looking into. Just got a push-back hard, from multiple
> directions, saying that we're rewriting the whole thing to only use
> tomcat anyway.


It seems as if it has already been evaluated and a decision has
been made.

Arne
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      09-08-2011
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


 
Reply With Quote
 
Torsten Kirschner
Guest
Posts: n/a
 
      09-18-2011
Den 08.09.2011 23:41, skrev Arne Vajhøj:
> On 9/8/2011 1:53 PM, 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?

>
> Tomcat is a web container only (Java EE Web Profile in
> Java EE 6 terminology).

[...]
> You don't have EJB, JCA, JTA, JMS etc..

[...]

Using the Spring Framework ( http://www.springsource.org/ ), one gets
most of the above, except EJB, I guess. Add Hybernate and you're set.



 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      09-18-2011
On 11-09-18 07:30 PM, Torsten Kirschner wrote:
> Den 08.09.2011 23:41, skrev Arne Vajhøj:
>> On 9/8/2011 1:53 PM, 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?

>>
>> Tomcat is a web container only (Java EE Web Profile in
>> Java EE 6 terminology).

> [...]
>> You don't have EJB, JCA, JTA, JMS etc..

> [...]
>
> Using the Spring Framework ( http://www.springsource.org/ ), one gets
> most of the above, except EJB, I guess. Add Hybernate and you're set.
>

And as Cay Horstmann put it in
http://weblogs.java.net/blog/cayhors...-20-and-tomcat,
when describing how to set up JSF 2.0 and Java EE 6 EL and CDI and bean
validation and JPA (to some extent):

"But even if you don't, ask yourself what you gain from the Tomcat pain.
GlassFish v3 is very fast, easy to manage, and, due to its modular
nature, you get as much or as little of EE 6 as you want."

Or as Lincoln Baxter put in
http://ocpsoft.com/java/why-doesnt-j...-complicated/:

"Trust me, the reason people have thought Java EE sucks, is because they
try to do this stuff on Tomcat, and say 'Why doesn’t (JPA, JMS, JTA,
EJB, JSF, CDI) work?'...Tomcat, Jetty, and other 'Servlet Containers'
all have these issues – that’s why they are called Servlet Containers."

Using Spring and a JPA provider and God knows what else with Tomcat,
just so it'll approach the capability provided by a proper Java EE
server, is exactly the same thing that Cay and Lincoln were advising
against. It's unnecessary, wasteful, error-prone, unproductive, and
misguided. Furthermore, the management capabilities provided by all
modern Java EE application servers blow Tomcat completely out of the water.

I use Tomcat myself and have used servlet containers ever since they
appeared. Echoing the comments of the two quoted guys, no disrespect
intended to Tomcat or any other servlet container, use a servlet
container for what they give you out of the box: don't try and make
imitations of Java EE servers out of them.

AHS
--
job creator: US Republican term for a wealthy party contributor

 
Reply With Quote
 
Torsten Kirschner
Guest
Posts: n/a
 
      09-19-2011
Den 9/19/11 1:44 AM, skrev Arved Sandstrom:
> On 11-09-18 07:30 PM, Torsten Kirschner wrote:
>> Den 08.09.2011 23:41, skrev Arne Vajhøj:
>>> On 9/8/2011 1:53 PM, 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?
>>>
>>> Tomcat is a web container only (Java EE Web Profile in
>>> Java EE 6 terminology).

>> [...]
>>> You don't have EJB, JCA, JTA, JMS etc..

>> [...]
>>
>> Using the Spring Framework ( http://www.springsource.org/ ), one gets
>> most of the above, except EJB, I guess. Add Hibernate and you're set.
>>

>

[... spherical cows in an EJB container ...]
> AHS


The OP's clearly stated premise was being limited to a given web
container.









 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Hot Requirements: 1.Sr Java Developer,2.Java Developer (Java with EJB) Isaac Java 0 01-20-2011 08:41 PM
hey i am just started java,, can anyone tell me the use ,application, why java , importance of java.. manish sahu Java 3 02-14-2008 12:00 AM
[JAVA] [EVALUATION] - The Java Failure (Sorry: The Java(tm) Failure) Ilias Lazaridis Java 0 02-01-2005 10:32 AM
JAVA VIRTUAL MUCHINE OR SUN JAVA Fernando Kohan Firefox 1 11-14-2004 02:04 AM
Job to convert Java App 1.3.1 to Java Newest of Java Michael Kintner Java 0 11-30-2003 04:42 AM



Advertisments