From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25134 invoked by alias); 18 Oct 2005 02:37:34 -0000 Mailing-List: contact mauve-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sources.redhat.com Received: (qmail 25116 invoked by uid 22791); 18 Oct 2005 02:37:32 -0000 Received: from 24-159-201-143.dhcp.roch.mn.charter.com (HELO alice.cabbey.net) (24.159.201.143) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 18 Oct 2005 02:37:32 +0000 Received: by alice.cabbey.net (Postfix, from userid 65000) id 4A67DE665F; Mon, 17 Oct 2005 21:37:30 -0500 (CDT) Received: from chesire.cabbey.net (chesire.cabbey.net [10.20.30.64]) by alice.cabbey.net (Postfix) with ESMTP id 1100CE665D for ; Mon, 17 Oct 2005 21:37:29 -0500 (CDT) From: Chris Abbey To: mauve-discuss@sources.redhat.com Subject: Re: tests with rmic Date: Tue, 18 Oct 2005 02:37:00 -0000 User-Agent: KMail/1.8 References: <4353DBB0.10807@menlina.com> In-Reply-To: <4353DBB0.10807@menlina.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510172137.28552.jikes@cabbey.net> X-SW-Source: 2005-q4/txt/msg00011.txt.bz2 On Monday 17 October 2005 12:13, Nicolas Geoffray wrote: > rmiregistry & > jamvm ReceiveObjectImpl & > jamvm Main > > Any suggestions? Mauve style guidelines aside (because I have no idea what they would encourage here), I'd encourage you not to start the default rmiregistry in any test framework, as it creates a dependency on the runtime environment. (Specifically that whoever is running the testcase doesn't already have an rmi registry up.) Instead, I'd suggest that the ReceiveObjectImpl class binds your own registry to an off the wall port that you've selected, and then in the test case, you locate on that same port. This does create the problem that you'll have to pick a port that's not in use, one solution to that is to use a fallback pattern to select the port and write it to a file that the test case loads to find out where the registry is. Also, by creating the registry in the test server, you ensure that it goes away when the test is done. The test server should also have a dead man's switch to exit after a finite amount of time, otherwise you have to try to ensure some cleanup externally, and most of the ways I've seen of doing that have some *bad* side effects. (case in point at work, we have a few very large shared development machines, occasionally, folks would get failures in some of the test buckets they were running that just didn't make sense... further digging found a test case like this that wanted to clean up after itself, so it did a ps list and killed any task with it's name in it. This works fine as long as there is only one instance of the test suite running. Another routinely killed the snmpd on the system, because the test case fired up it's own with a unique config, on the default port, and then when the test failed because it was running iwht the wrong snmpd config, it blasted all instances of snmpd on the box.) Anyway, client/server test cases usually need some extra thought put into them was my only point before I started rambling. /me re-lurks now. -- Never make a technical decision based upon the politics of the situation. Never make a political decision based upon technical issues. The only place these realms meet is in the mind of the unenlightened. -- Geoffrey James, The Zen of Programming