Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe08.iad.POSTED!8ad76e89!not-for-mail From: Arved Sandstrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Java EE on tomcat? References: <4e69368f$0$303$14726298@news.sunsite.dk> <12076840.62.1316629181108.JavaMail.geo-discussion-forums@vbac9> <5650f182-359d-42a2-9566-b75c3b8133b4@bi2g2000vbb.googlegroups.com> In-Reply-To: <5650f182-359d-42a2-9566-b75c3b8133b4@bi2g2000vbb.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lines: 47 Message-ID: X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Wed, 21 Sep 2011 20:37:30 UTC Organization: Public Usenet Newsgroup Access Date: Wed, 21 Sep 2011 17:37:29 -0300 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8182 On 11-09-21 03:31 PM, nroberts wrote: > On Sep 21, 11:19 am, Lew wrote: >> nroberts wrote: >>> Apparently the decision to move to Tomcat was simply one of >>> standardization. I think perhaps the decision was made a while back. >> >> "Let's standardize on Betamax for our on-demand movie streaming service." >> >> Standardization is good as long as the standard actually applies to the problem domain. >> >>> At any rate it was made without me for reasons I do not know. I was >>> told though, when I mentioned being worried that such limits could >>> increase development effort, that I can use whatever libraries or >>> extensions I need. This includes things like OpenEJB etc... >> >> As others pointed out, this is not a good approach. If you need all those things, better to go with Glassfish or Geronimo or JBoss where it's already all there, and just about as lightweight as Tomcat without those things. > > You're preaching to the choir here. Giving me hell for using > something I'm forced to use isn't going to help me. I have a task. I > have constraints. It is what it is. Given the choice I'd be using an > app server instead of trying to figure all this crap out. I wasn't > given one. In your shoes I think, at this point, I'd whip up a written technology assessment that explains exactly what vanilla Tomcat is capable of. If you've been given to understand that the motivation is standardization, then explain in that assessment that only certified-compliant Java EE applications servers are standardized for Java EE. Also explain in that document what they will not get even with a Tomcat that you've enhanced. You clearly already know this, but cobbling together a slice of Java EE with a dozen or more third-party JARs and jamming them into Tomcat is a recipe for every kind of maintenance and development nightmare. Think of this document as not only a good-faith attempt to educate your people, but also a potential CYA for when things start going south. Add into the document a clear evaluation of configuration management impact - how many extra third party JARs are needed, who are these third party JARs from, what is the choice available for each API/specification, how much extra work is entailed in including these things, etc. My hunch is that whoever made this decision is ignorant. I don't mean stupid; I just mean ignorant. Which means they can be educated. In theory. AHS