james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Emacs and Eclipse
Date Sun, 12 Nov 2006 23:31:36 GMT
J├╝rgen Hoffmann wrote:

> No one on this list is telling you to use one, nor telling you
> that they are so much better. You asked if it is possible to
> run one single Unit Test.

And since no one else knew how, I took care of it.

> But please stop complaining about how long Unit Tests take,

You might notice that Danny and others also commented on the issue, and no
one disagreed that it was a concern.

> and about how hard it is to find a solution to your problem.

It wasn't at all hard to solve the problem, once someone (me) took the time
to look for a solution.

> What does all of this say? Nothing, correct. It all boils down to personal
> likings and dislikings.

Right.  And so we should make sure that everyone, not just people using
IDEs, are supported.

> One more thing about the memory leak. First, I am happy you were proven
> found, and fixed the bug. But I would be more happy if there was an
> automated test exposing the bug before fixing it.

I've said the same thing.  Life doesn't always work out that way.

> For simulating simultaneous connections, maybe this test lib could be of
> use: http://www-128.ibm.com/developerworks/java/library/j-contest.html

No help at all.  It wasn't a matter of simultaneous connections, for which
we have test drivers.  It was a matter of 100s of 1000s of client IP
addresses and their host names.  Simulating that is the challenge.

But we have known for years that, generically speaking, the defect is
allowing InetAddress to do name resolution.  So setting the documented
Security property would "solve" the problem, although masking its presence,
and the proposed DNS resolver would warn administrators of the presence of
defective code.  If we'd had that code in place, it would have warned us of
the one line of code per handler that was responsible for the problem.

	--- Noel

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message