Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 14251 invoked from network); 24 Jan 2003 17:09:55 -0000 Received: from exchange.sun.com (192.18.33.10) by 208.185.179.12.available.above.net with SMTP; 24 Jan 2003 17:09:55 -0000 Received: (qmail 9476 invoked by uid 97); 24 Jan 2003 17:10:46 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 9389 invoked by uid 97); 24 Jan 2003 17:10:45 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 9247 invoked by uid 98); 24 Jan 2003 17:10:44 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Single Servlet vs Multiple Servlet Date: Fri, 24 Jan 2003 12:09:14 -0500 Message-ID: <66337F04F2A1E440BF87F2080B5F537001481BA1@madison.dc.Blackboard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Single Servlet vs Multiple Servlet Thread-Index: AcLDypSo+AfpAmZITvC/B/7OpOkiJwAADPiA From: "Tim Moore" To: "Tomcat Users List" X-OriginalArrivalTime: 24 Jan 2003 17:09:14.0799 (UTC) FILETIME=[526603F0:01C2C3CB] X-Spam-Rating: 208.185.179.12.available.above.net 1.6.2 0/1000/N X-Spam-Rating: 208.185.179.12.available.above.net 1.6.2 0/1000/N > -----Original Message----- > From: Robert Simmons [mailto:derisor@arcor.de]=20 > Sent: Friday, January 24, 2003 12:04 PM > To: Tomcat Users List > Subject: Re: Single Servlet vs Multiple Servlet >=20 >=20 > Actually I don't intend to use JSP at all. The resulting=20 > document from the call to the servlet is XML, not HTML or=20 > XHTML or JSP. Just XML. I'm not sure learning a JSP framework=20 > would be worth my time. Struts isn't exactly a JSP framework. It's a servlet command pattern = framework, that happens to include some JSP tag libraries to make it = easier to use with JSP. But it was explicitly designed to be agnostic = of the presentation method used, and people have used it successfully = with Velocity, XML/XSLT, etc. The framework is actually pretty simple, so it's worth at least taking a = look at it so that you don't end up just reinventing the wheel. You may = decide to implement your own anyway for one reason or another, but it = can't hurt to check it out and possibly steal some ideas. :-) --=20 Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 >=20 > -- Robert >=20 >=20 > ----- Original Message ----- > From: "Felipe Schnack" > To: "Tomcat Users List" > Sent: Friday, January 24, 2003 5:46 PM > Subject: RE: Single Servlet vs Multiple Servlet >=20 >=20 > Yes, I think there's no reason why you should implement=20 > your application hand-coding a servlet for each "command" you=20 > need. There are several frameworks around the web that you=20 > can use... Apache Struts, JCorporate Expresso (that now is=20 > integrated to Struts) and others. Personally, I'm developing=20 > some applications using my own framework, that consists of=20 > taglibs (I don't use scriptlets at all), special classes to=20 > handle your "commands" (or "actions" in Struts), database=20 > abstraction layer, etc... > I personally like to make one by myself, even if just for=20 > fun (and to learn how to do it), but mainly because of time=20 > constraints probably you'll need some of these frameworks=20 > found in the web. >=20 > On Fri, 2003-01-24 at 14:39, Shapira, Yoav wrote: > > Howdy, > > > > >In all there will be about 50 commands that can be done to this > > servlet. If > > >I put them all in one file it would violate my sense of object=20 > > >oriented engineering. So I thought of either making the various=20 > > >commands > > actually be > > >in different classes and the servlet routing the requests to the=20 > > >proper command. The alternative is to make individual command=20 > > >servlets that > > have a > > >common base class and sit on separate URLs. > > > > > >The problem with option two is that the servlet connects to EJB on=20 > > >the > > back > > >end and could potentially hold onto allot of resources. The problem > > with > > >option two, possibly, is federation. If there are hundreds of=20 > > >requests coming, will tomcat federate the servlet or pipe=20 > everything=20 > > >through one hole? > > > > 1. Take a look at struts. It will handle the direction of=20 > the request=20 > > to the proper resource based on the 50 actions (which you call=20 > > "commands" above) you define. > > > > 2. Simply put: don't worry about federation. Let tomcat=20 > worry about=20 > > how many instances of the servlet it needs, how many request=20 > > processing threads it needs, etc. Tomcat does a good job=20 > at this, and=20 > > some of the relevant parameters (maxProcessors etc.) are=20 > user-tunable=20 > > as well. We, as well as many other people on this list, run tomcat=20 > > instances that handle thousands of requests. > > > > Also, you can always switch containers if you find tomcat doesn't=20 > > handle your traffic volume as well as you'd like... > > > > Yoav Shapira > > Millennium ChemInformatics > > > > -- > > To unsubscribe, e-mail: =20 > unsubscribe@jakarta.apache.org> > > For=20 > additional commands,=20 > e-mail:=20 > > > > > -- >=20 > Felipe Schnack > Analista de Sistemas > felipes@ritterdosreis.br > Cel.: (51)91287530 > Linux Counter #281893 >=20 > Centro Universit=E1rio Ritter dos Reis=20 > http://www.ritterdosreis.br > ritter@ritterdosreis.br >=20 > Fone/Fax.: (51)32303341 >=20 >=20 > -- > To unsubscribe, e-mail: =20 > unsubscribe@jakarta.apache.org> > For=20 > additional commands,=20 > e-mail: >=20 >=20 > -- > To unsubscribe, e-mail: =20 > unsubscribe@jakarta.apache.org> > For=20 > additional commands,=20 > e-mail: >=20 >=20 -- To unsubscribe, e-mail: For additional commands, e-mail: