From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29050 invoked by alias); 18 Oct 2005 11:47:25 -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 29038 invoked by uid 22791); 18 Oct 2005 11:47:23 -0000 Received: from isis.lip6.fr (HELO isis.lip6.fr) (132.227.60.2) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 18 Oct 2005 11:47:23 +0000 Received: from src.lip6.fr (src.lip6.fr [132.227.64.100]) by isis.lip6.fr (8.13.1/jtpda-5.4+victor) with ESMTP id j9IBlJ2M029590 ; Tue, 18 Oct 2005 13:47:20 +0200 X-pt: isis.lip6.fr Received: from [132.227.64.153] (dormeur [132.227.64.153]) by src.lip6.fr (8.12.9-20030917/jtpda-5.4+victor) with ESMTP id j9IBlH9B009201 ; Tue, 18 Oct 2005 13:47:19 +0200 Message-ID: <4354E0C3.1000108@menlina.com> Date: Tue, 18 Oct 2005 11:47:00 -0000 From: Nicolas Geoffray User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050913) MIME-Version: 1.0 To: audriusa@bluewin.ch CC: mauve-discuss@sources.redhat.com Subject: Re: tests with rmic! References: <4353DBB0.10807@menlina.com> <4354B543.1090404@bluewin.ch> In-Reply-To: <4354B543.1090404@bluewin.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b2 (isis.lip6.fr [132.227.60.2]); Tue, 18 Oct 2005 13:47:20 +0200 (CEST) X-SW-Source: 2005-q4/txt/msg00013.txt.bz2 Hi Meskauskas, Meskauskas Audrius wrote: > Hi, Nicolas, > > Nice idea, great to have at least any java.rmi rests! The current > testing situation with this package is deeply tragical, the coverage > being plain zero. And it is possible to find random talks on the web > like "how reliable they (GNU Classpath) RMI implementation is? Does it > work?". > > Any tests are very welcome. > > I think it would be a good idea to write Mauve tests as the > independent modules that run on a single virtual machine and does call > external tools. The most of the current tests are written this way. > Here are several suggestions how to make an ordinary Mauve test that > would not need to cross the boundaries of the current virtual machine > to run: > > 1. Instead of starting three independent virtual machines (one for > server, one for client and one for the naming service), you can just > start three threads. When all cleanup problems, if any, will be > restricted to the current run of the test suite. I can't use threads in a same virtual machine, because there is no serialization of objects in RMI when the server and the client lives in the same virtual machine (maybe it's possible enabling a flag somewhere, but i don't know the API) > 2. Instead of invoking rmic from inside the Mauve test, run it once > with the -keep key and just add the generated source code file to your > path. Such test would be easier to debug. Allright. Good idea Bye, Nicolas