tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Ward" <cw...@go-integral.com>
Subject RE: Single Servlet vs Multiple Servlet
Date Fri, 24 Jan 2003 18:02:48 GMT
If you are XML based, how about the Apache Cocoon project. I have only read about it, not tried
it.

Chris


-----Original Message-----
From: Robert Simmons [mailto:derisor@arcor.de]
Sent: Friday, January 24, 2003 11:04 AM
To: Tomcat Users List
Subject: Re: Single Servlet vs Multiple Servlet


Actually I don't intend to use JSP at all. The resulting document from the call to the servlet
is XML, not HTML or XHTML or JSP.
Just XML. I'm not sure learning a JSP framework would be worth my time.

-- Robert


----- Original Message -----
From: "Felipe Schnack" <felipes@ritterdosreis.br>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Sent: Friday, January 24, 2003 5:46 PM
Subject: RE: Single Servlet vs Multiple Servlet


  Yes, I think there's no reason why you should implement your
application hand-coding a servlet for each "command" you need. There are
several frameworks around the web that you can use... Apache Struts,
JCorporate Expresso (that now is integrated to Struts) and others.
Personally, I'm developing some applications using my own framework,
that consists of taglibs (I don't use scriptlets at all), special
classes to handle your "commands" (or "actions" in Struts), database
abstraction layer, etc...
  I personally like to make one by myself, even if just for fun (and to
learn how to do it), but mainly because of time constraints probably
you'll need some of these frameworks found in the web.

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 oriented
> >engineering. So I thought of either making the various commands
> actually be
> >in different classes and the servlet routing the requests to the proper
> >command. The alternative is to make individual command 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 the
> back
> >end and could potentially hold onto allot of resources. The problem
> with
> >option two, possibly, is federation. If there are hundreds of requests
> >coming, will tomcat federate the servlet or pipe everything through one
> >hole?
>
> 1. Take a look at struts.  It will handle the direction of the request
> to the proper resource based on the 50 actions (which you call
> "commands" above) you define.
>
> 2. Simply put: don't worry about federation.  Let tomcat worry about how
> many instances of the servlet it needs, how many request processing
> threads it needs, etc.  Tomcat does a good job at this, and some of the
> relevant parameters (maxProcessors etc.) are user-tunable as well.  We,
> as well as many other people on this list, run tomcat instances that
> handle thousands of requests.
>
> Also, you can always switch containers if you find tomcat doesn't handle
> your traffic volume as well as you'd like...
>
> Yoav Shapira
> Millennium ChemInformatics
>
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
>
--

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message