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 and > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
