All of it is necessarily not evil. I just made use of a feature provided by the
servlet designers. My application consists of a set of cooperating servlets. One
servlet provides DBMS connection services, one provides CTREE and Mainframe
communication services, one provides connections to a messaging server. These
servlets are started, when the servlet engine is started. On startup, they read
connection params., do necessary initializations, open connections, and get ready
to provide communication services when the "worker" servlets demand a comm.
service. The "factory worker" servlets request a comm. object from these
connection keepers, they do their work using the comm. objects, and return them to
their keepers when they are done.
Santhosh
Calin Tenitchi wrote:
> That is what the "application" object should solve. Whatever you wanted to get
> from that servlet is evil. You should use some "proxy" object like the
> application to do that stuff for you.
>
> Servlet spec 2.2 takes the "web application" concept further and reaches almost
> perfection. I can't wait until it is implemented!
>
> Santhosh Annira <[EMAIL PROTECTED]> on 1999-10-05 16:59:35
>
> Please respond to Santhosh Annira <[EMAIL PROTECTED]>
>
> To: [EMAIL PROTECTED]
> cc: (bcc: Calin Tenitchi/netset/se)
>
> Subject: Re: Servlet Zones
>
> Craig,
>
> Thanks for the clarifications. I am all for servlets. I have already delivered
> products
> using servlets. Actually, I am spoilt by all the features that servlets support.
> My code
> hinges on the - getServletContext().getServlet("ServletName')- feature (I
> ignored the
> the warning note in Sun's documentation) . I am wondering how to fix my
> production code,
> when that feature goes away in the new servlet API specification. Do you have
> any insights
>
> ?
>
> Thanks
> Santhosh.
>
> "Craig R. McClanahan" wrote:
>
> > Santhosh Annira wrote:
> >
> > > Craig,
> > >
> > > I feel that, running separate JVMs is an overkill, and it defeats the
> whole
> > > idea behind using servlets instead of old fashioned CGI processes. JVMs
> have
> > > considerable startup time
> >
> > When running Apache JServ with separate JVMs, you do this yourself, separate
> from the
> > web server. Typically, an ISP would start the JVM for each of their hosting
> customers
> > once, and it would stay running all the time. This is totally unlike CGI,
> where you
> > have to pay the process startup cost on every single request.
> >
> > > and each JVM needs a separate port number.
> >
> > With 63k of them available (you don't get to use ports < 1024 unless you're
> root), I
> > hardly think this is going to cause you any grief :-).
> >
> > The port numbers required are also invisible to users of the servlet-based web
> sites,
> > since they are only for communication between Apache and the JVMs. These port
> numbers
> > are not visible in the URLs that people accessing the web sites use.
> >
> > > Also, there
> > > could be a limit on the number of JVMs that you can run. JVMs are started
> when
> > > Apache server is started, and how do we decide how many to start initially
> (one
> > > per every user ?).
> >
> > The separate-JVM-per-user approach is the most secure, but I have seen ISPs
> that offer
> > two-tiered prices -- a higher price for a separate JVM, or a lower price if
> you're
> > willing to share JVMs with other customers (each in their own zone), at the
> modest
> > risk that the other customers you are sharing with might cause you a problem
> (like
> > executing System.exit()). The sysadmin sets up separate JVMs or not based on
> customer
> > request, just like they set up DNS entries, mailboxes, virtual hosts, database
> > connections, and everything else uniquely per customer. If they are doing it
> a lot,
> > they've got scripts to do all the grunt work.
> >
> > The Apache JServ zone approach also allows you to run the JVMs on separate
> servers, if
> > you want. At the cost of hardware nowdays, it's not that tough to get real
> quick
> > paybacks on the hardware investment required for this.
> >
> > Note also that heavily used CGI-based apps on shared servers have memory-usage
> impacts
> > as well ... different ones, but still real.
> >
> > > Only Apache servlet engine is free. For JRUN, the amount that
> > > you pay, depends on the number of JVMs that you wish to run. WebSphere lets
> you run
> > > only one JVM per machine.
> > >
> >
> > The only reason I bothered to respond to your initial comments at all was to
> point out
> > the incorrectness of your blanket assertions about zones. If you like CGI,
> then by
> > all means stay with it ... but my apps, even in shared environments, are going
> to be
> > servlet+JSP based.
> >
> > >
> > > cheers
> > > Santhosh
> > >
> >
> > Craig
> >
> > ===========================================================================
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> > FAQs on JSP can be found at:
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
>
> ===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
> FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
