Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Wed, 31 May 2006 14:33:39 +0200
From: Olav Sandstaa <Olav.Sandstaa@Sun.COM>
Subject: Re: jdk16 and suite derbyall - 128 failures
In-reply-to: <c25576af0605310416qc8943cbj11a8974b95aab505@mail.gmail.com>
Sender: Olav.Sandstaa@Sun.COM
To: derby-dev@db.apache.org
Message-id: <447D8D23.7070904@sun.com>
Organization: Sun Microsystems - Trondheim, Norway
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <836ae9af0605101709w12a02835n7aabf25b95e5c8bd@mail.gmail.com>
 <446C27DF.4030603@sun.com> <446C62DE.7020207@sun.com>
 <446C76EC.4060500@sun.com> <446E3D6F.5030605@sun.com>
 <446E5265.1020004@sun.com> <447313C2.80906@sun.com>
 <44743415.1060402@sun.com>
 <44746C4D.9090700@apache.org> <4477828B.1010302@sun.com>
 <c25576af0605310416qc8943cbj11a8974b95aab505@mail.gmail.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060427)

Myrna van Lunteren wrote:
> On 5/26/06, Olav Sandstaa <Olav.Sandstaa@sun.com> wrote:
>> So how should we fix this? Any suggestions? Some ideas:
>>
>> * Remove the support for autoloading of the embedded driver (Yes, Rick
>> and the JDBC4 expert group have already said no to this, but I still
>> think there are situations where automagic loading of the drivers is a
>> bad idea)
>>
>> * Change the test harness so that derby.system.home is set to a value
>> that is OK for all tests suites (running with useprocess=false) early
>> during initialization (before touching any JDBC driver code)
>>
>> * Change the  RunSuite(?) code so that it unloads the embedded driver
>> and the engine as part of the start  up  (to get rid of the autoloaded
>> embedded driver)
>>
>> * Change the "security manager" properties for  the  Nist tests to avoid
>> the security exception when the VM tries to get the canonical path for
>> the working directory.
>>
>> Any preferences or suggestions for better ideas?
>>
>> Thanks,
>> Olav
>>
> I think setting derby.system.home for useprocess=false runs may be
> achievable...even if we decide to keep the autoloading.
I agree that this is the easiest way to fix the problem. The "problem" 
with this solution is that we need to set it early during startup of 
derbyall (before any JDBC driver is attempted loaded) and that this 
derby.system.home location will be used by all suites running with 
useprocess=false. Another issue with this solution is to decide what 
directory we should set it to. Should we set derby.system.home to the 
current directory where derbyall is started? This would potentially 
leave files in the top directory that could influence on other test 
suites. Or should we make a sub directory that is common for all suites 
running with useprocess=false (and jdk16)? Any suggestion for what value 
we should assign to derby.system.home if we decide to do this?

> Another option may be to add additional permissions to the
> useprocessfalse.policy file in functionTests/util...would that be
> acceptable (if it works)? I guess it would need user.dir read? for
> derby.jar? (user.dir read appears to be in place - in
> derby_tests.policy - currently for derbytools.jar, derbyTesting.jar
> and classes).
I think this would work, at least if I disable the security manger the 
Nist tests succeed. The drawback with this solutions is that it too will 
use the directory where derbyall was started for creating the database 
and storing files containing test results.

Right now I am experimenting with a solution that attempts to unload the 
embedded driver each time a new suite with useprocess=false is started. 
If this works I think this will be the best solution since then each 
suite can set derby.system.home to the directory they want the test to 
run in and then load the driver and engine. Any objections to this 
approach? (I do not know yet if it will work)

> While this gets hashed out further, maybe it's time to create a
> separate bug for this, and document the investigative work there...

I agree. I will file a JIRA for this and make a summary.

> Then maybe we can stop jdk16 from running nist (runwithjdk16=false in
> nist.properties) for the time being, so we don't lose the signal value
> of the automatic reports...

Good idea. Unless someone with the right permissions to get this quickly 
into the svn repository will do it, I can make a patch for this change 
to the property file.

Regards,
Olav