in general, i am not big on ide's, but have found VAJ 2.x to be very
useful for server-side java development, and integration to legacy
systems. the servlet and JSP debugging support is excellent.
> Nelson wrote:
>
> I'd like to hear your opinions about the development tools available.
> I've bee
On Tue, 18 May 1999, Craig R. McClanahan wrote:
>...
> The data stored with context.setAttribute() is only "public" within a particular
> servlet context. If you don't trust the code in a servlet written by someone else,
> set it up in it's own context and you don't have this risk.
>
Cezar Totth wrote:
> On Tue, 18 May 1999, David Mossakowski wrote:
>
>
> > You can store variables that will be common to all threads by putting them in
> > context. (context.setAttribute())
> But then any other servlet (and those written at evil.programmers.org)
> will be able to grab that publi
Hans Bergsten wrote:
> What's needed then is ServletContext.getName() method that returns the
> registered name.
Agreed. But I believe that having to use getName() and setAttribute()
to write a simple counter servlet is overkill.
This is why I believe in the idea of having an interface (or some
Jason Hunter wrote:
>
> Craig R. McClanahan wrote:
> > As David points out, though, ServletContext.setAttribute() is
> > designed for sharing global data for the same servlet, or for
> > different servlets. The servlet context also serves as the
> > "Application" scope in JSP, for the same reason
You got me 'cause I was arguing about the "common" case. I didn't realize what you
meant by 'single instance'.
dave.
Cezar Totth wrote:
> On Tue, 18 May 1999, David Mossakowski wrote:
>
> > No servlet engine I know of creates two instances of a servlet the way you
> > describe it.
> There seem
> In fact, if you alias the same servlet class name to two different
> aliases in Apache JServ, you do get two instances -- one per alias.
> This is needed, because the lifecycles of each instance are managed
> individually Your "counter in an instance variable"
> then works the way you want, if
Jason Hunter wrote:
>
> One thing I miss with ServletContext.setAttribute() however is the
> ability to easily have different data kept per registered servlet
> name. For example, with JWS if you have a counter servlet
> registered as "counter" and registered also as "howmany" you will
> have tw
Craig R. McClanahan wrote:
> As David points out, though, ServletContext.setAttribute() is
> designed for sharing global data for the same servlet, or for
> different servlets. The servlet context also serves as the
> "Application" scope in JSP, for the same reason.
One thing I miss with Servlet
On Tue, 18 May 1999, David Mossakowski wrote:
> No servlet engine I know of creates two instances of a servlet the way you
> describe it.
There seem to be some... at least those distributed (dispatching
requests across multiple JVMs) pretend are capable of that.
> The init() method is "guarante
David Mossakowski wrote:
> No servlet engine I know of creates two instances of a servlet the way you
> describe it. The init() method is "guaranteed" (from Servlet API) to be called
> only once at start up.
>
> You can store variables that will be common to all threads by putting them in
> cont
No servlet engine I know of creates two instances of a servlet the way you
describe it. The init() method is "guaranteed" (from Servlet API) to be called
only once at start up.
You can store variables that will be common to all threads by putting them in
context. (context.setAttribute())
Check
On Mon, 17 May 1999, jon * wrote:
> > I would like a "SingleInstanceServlet" interface,
> > in order to force servlet engine NOT to create multiple
> > instances of a certain servlet.
> >
> > This would guarantee that all concurent requests share the same
> > local variables.
>
> Why in the world
> The only part I objected to was the "it encourages stupid people to
> stay stupid" part.
Like I said, your objection was based on a statement that was taken out of
context.
> I fully agree with you that the STM is no panacea. In fact, it can
> lead the unsuspecting
> in
> I would like a "SingleInstanceServlet" interface,
> in order to force servlet engine NOT to create multiple
> instances of a certain servlet.
>
> This would guarantee that all concurent requests share the same
> local variables.
Why in the world would you want to take the multi-user nature of s
ay, May 17, 1999 2:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Development tools
>
> > >>>In my opinion Sun made a mistake when including the STM
> model.
> > Essentially
> >>>>it encourages stupid people to stay stupid
> >
> &g
On Mon, 17 May 1999, Craig R. McClanahan wrote:
.
> I agree with Jon that STM is a bad thng.
>
> All harshness aside, there are multi-thread issues that SingleThreadModel does
> not address. Programmers that rely on it because they don't know how (or don't
> want to know how) to write multi-t
> >>>In my opinion Sun made a mistake when including the STM model.
> Essentially
it encourages stupid people to stay stupid
>
> Dont be so harsh! Many many programmers find it hard to write
> multi-threaded code.
> Dont forget that not all pgmrs have degrees in Computer Science!
>
>
"Emuleomo, Olu (PME)" wrote:
> >>>In my opinion Sun made a mistake when including the STM model.
> Essentially
> >>>it encourages stupid people to stay stupid
>
> Dont be so harsh! Many many programmers find it hard to write
> multi-threaded code.
> Dont forget that not all pgmrs have de
Science!
--Olu E.
> -Original Message-
> From: jon * [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 14, 1999 5:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Development tools
>
> > So it is totally useless for any servlet devo work and *no* knowledgable
> > pers
On Fri, 14 May 1999, Lauren wrote:
> At 05:20 PM 5/13/99 , jon * wrote:
> >
> >No "guru" here in his/her right mind would suggest using STM to
> >implement a servlet.
>
> So it is totally useless for any servlet devo work and *no*
> knowledgable person would suggest using it? Sun made a mistake i
A shared object is a singleton class that is referenced in a Servlet(s). To
create a shared object you can use somthing like this
public class Template {
private Template() { }
private static Template instance = new Template();
public staticTemplate getInstance() { return insta
Milt Epstein wrote:
> One thing servlet engines do to get
> around this is to create a pool of servlet instances, and if one
> instance is busy with a thread, one of the other instances will be
> used. This eliminates/reduces the performance penalty.
I believe this is only done in the case wh
At 05:20 PM 5/13/99 , jon * wrote:
>
>No "guru" here in his/her right mind would suggest using STM to implement a
>servlet.
>
So it is totally useless for any servlet devo work and *no* knowledgable
person would suggest using it? Sun made a mistake in including it in their
servlet API?
Really, I
> So it is totally useless for any servlet devo work and *no* knowledgable
> person would suggest using it? Sun made a mistake in including it in their
> servlet API?
In my opinion Sun made a mistake when including the STM model. Essentially
it encourages stupid people to stay stupid. I'm not say
> > When I first started writing servlets (coming up on two years ago) I didn't
> > know that one instance could serve several requests so my servlet had
> > problems when I moved it from servlet runner to a real web server. STM would
> > have saved me from rewriting some code back then.
>
If you
On Fri, 14 May 1999, Gabriel Wong wrote:
> Milt Epstein wrote:
>
> > One thing servlet engines do to get
> > around this is to create a pool of servlet instances, and if one
> > instance is busy with a thread, one of the other instances will be
> > used. This eliminates/reduces the performance
> Maybe I should elucidate a little further; the devo work I am doing is for
> an Intranet application which will have at the *most* a dozen or so
> concurrent connections and most often will have only 0-5 connections to the
> database. There is a webserver (NES) and a machine (Compaq Proliant)
>
> When I first started writing servlets (coming up on two years ago) I didn't
> know that one instance could serve several requests so my servlet had
> problems when I moved it from servlet runner to a real web server. STM would
> have saved me from rewriting some code back then.
No, it would hav
At 09:50 AM 5/14/99 , Lauren wrote:
>Is there a resource you could point me to that would tell me why the STM
>should not be used for servlet devo work, or maybe you could explain for my
>benefit?
>
Maybe I should elucidate a little further; the devo work I am doing is for
an Intranet applicatio
Le 08:05 14/05/99 -0400, Adam Smith a écrit:
>Do you have any resources you can recommend for learning about pooling
>connections (preferrably online). Thanks.
Hello,
Have a look at the JDBC section on my page at http://www.interpasnet.com/JSS
Hope this helps
+--
At 02:53 PM 5/14/99 , you wrote:
>In my opinion Sun made a mistake when including the STM model. Essentially
>it encourages stupid people to stay stupid. I'm not saying that you are
>stupid, I'm just saying that it really does nothing to help newbies learn
>how to write code the correct way.
Wel
> At 05:20 PM 5/13/99 , jon * wrote:
> >
> >No "guru" here in his/her right mind would suggest using STM
> to implement a
> >servlet.
> >
>
> So it is totally useless for any servlet devo work and *no*
> knowledgable
> person would suggest using it? Sun made a mistake in
> including it in their
>
Adam Smith wrote:
>
> Do you have any resources you can recommend for learning about pooling
> connections (preferrably online). Thanks.
I wrote an article, with source code, for Web Developer's Journal about
connection pools a while back, see
http://WebDevelopersJournal.com/columns/connection_po
I heartily agree with Jon on this one. Connection pools are just not that
hard to deal with. Just go here: http://www.javaexchange.com/ and start
reading and downloading.
-Eric
At 08:05 AM 5/14/99 -0400, you wrote:
>Do you have any resources you can recommend for learning about pooling
>connecti
> Well, let's use the word "ignorant" instead of "stupid" since that is what
> we are really talking about here; whereas ignorance is a lack of knowledge
> and stupidity is the inability to reason or make intelligent decisions.
> Everyone is ignorant on one subject or another - most people should
Hans,
I'd recommend to replace new Date().getTime(); by
System.currentTimeMillis(); for better performance.
Dmitry.
- Original Message -
From: Hans Bergsten <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 14, 1999 11:10 AM
Subject: Re: Development tools
&
"Rogatkin, Dmitry" wrote:
>
> Hans,
> I'd recommend to replace new Date().getTime(); by
> System.currentTimeMillis(); for better performance.
Thanks, you're right. I've already made that change in the
implementation we use, but I'll correct the article as well.
There's also a bug in the recursio
Do you have any resources you can recommend for learning about pooling
connections (preferrably online). Thanks.
At 05:20 PM 5/13/99 -0700, you wrote:
>> I am on a team of two developing a small project using a single servlet
>> implementing the SingleThreadModel.
>
>> This is my first project wi
> I am on a team of two developing a small project using a single servlet
> implementing the SingleThreadModel.
> This is my first project with servlets, but I am doing it this way on the
> advice of several other servlet gurus here at work.
No "guru" here in his/her right mind would suggest usi
At 01:00 PM 5/13/99 , Nelson wrote:
>
> I'd like to hear your opinions about the development tools available.
> I've been testing Jbuilder2, but I saw that it uses a proprietary api to
> manage database access. Also, I didn't find it easy to debug servlets. Which
> one are you using and best deal
At 01:47 PM 5/13/99 , K Shaikh wrote:
>
> We're developing a large project using Servlets.
> We are trying to decide between using a single
> big servlet responding to all HTTP requests or a
> bunch of smaller ones to server different
> types of requests. Does anyone
> have any ideas why one may b
> I have developed a few projects with servlets and can give you the following
> advice. One big servlet defeats the current movement toward componentizing
> applications. One big servlet is very tough to debug, update, and is not
> practical to use in other projects because it is doing to many
I have developed a few projects with servlets and can give you the following
advice. One big servlet defeats the current movement toward componentizing
applications. One big servlet is very tough to debug, update, and is not
practical to use in other projects because it is doing to many things w
I am developing my servlets using PowerJ, and it is very easy to connect
to the database. All the database connections/query management can
be done visually, and it uses the standard JDBC plus some wrapper classes
that make life easier, and it can be used with java 1.1 or 1.2. I
think you can
Nelson:
I've gone through a fair number of different Java development tools,
editors, IDE's and have lately been doing pretty well with Elixir - it's an
IDE built entirely out of Java (you get a JAR file when you buy it -
inexpensive too), so I can flip between platforms & stick with the same IDE
We're
developing a large project using Servlets.
We are
trying to decide between using a single
big
servlet responding to all HTTP requests or a
bunch
of smaller ones to server different
types
of requests. Does anyone
have
any ideas why one may be better than the other?
Thanks
a bunch
Nelson,
I'm using JPadPro for servelts and JavaWorkshop 2.0 for applets.
JPadPro has the possilities of compiling using Microsoft Classes and
Sun Classes.
Java Workshop is from Sun and uses only Sun Classes. It's 100% Pure
Java. For Data Acess I'm using JDBC and i have no problems!
http://www.mo
48 matches
Mail list logo
