You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Daniel John Debrunner <dj...@debrunners.com> on 2005/05/26 18:40:58 UTC
J9 Foundation & RunSuite
Myrna, your changes to RunTest for WCTME 5.7 (J9) enabled me to get it
running with J9/JSR169 but RunSuite fails with errors parsing a version
number. The version being parsed and causing the exception in
JavaVersionHolder is
J2ME Foundation Specification v1.0
What should the field values be in JavaVersionHolder to match the
changes you made in RunTest? (ie. minor, major version)
And does this mean that RunTest and RunSuite have separate mechanisms to
determine the identity of a VM?
Thanks for any help,
Dan.
+ c:/_work/p4/djdt1/wctme5.7/ive/bin/j9 -jcl:foun10
-Xbootclasspath/p:c:/_work/p4/djdt1/wctme5.7/ive/lib/jdbc.jar
org.apache.derby.tools.sysinfo
------------------ Java Information ------------------
Java Version: J2ME Foundation Specification v1.0
Java Vendor: IBM Corporation
Java home: c:\_work\p4\djdt1\wctme5.7\ive
Java classpath:
c:/_work/svn/trunk/classes;c:/_work/svn/trunk/tools/java/jakarta-oro-2.0.8.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1 build 2600 Service Pack 1
Java user name: djd
Java user home: C:\Documents and Settings\Administrator
Java user dir: C:\_work\svn\trunk\systest\out
java.specification.name: J2ME Foundation Specification
java.specification.version: 1.0
--------- Derby Information --------
JRE - JDBC: J2ME - JDBC for CDC/FP 1.0
[C:\_work\svn\trunk\classes] 10.1.0.0 alpha - (1)
------------------------------------------------------
----------------- Locale Information -----------------
Current Locale : [English/United States [en_US]]
Found support for locale: [de_DE]
version: 10.1.0.0 alpha - (1)
Found support for locale: [es]
version: 10.1.0.0 alpha - (1)
Found support for locale: [fr]
version: 10.1.0.0 alpha - (1)
Found support for locale: [it]
version: 10.1.0.0 alpha - (1)
Found support for locale: [ja_JP]
version: 10.1.0.0 alpha - (1)
Found support for locale: [ko_KR]
version: 10.1.0.0 alpha - (1)
Found support for locale: [pt_BR]
version: 10.1.0.0 alpha - (1)
Found support for locale: [zh_CN]
version: 10.1.0.0 alpha - (1)
Found support for locale: [zh_TW]
version: 10.1.0.0 alpha - (1)
------------------------------------------------------
+ c:/_work/p4/djdt1/wctme5.7/ive/bin/j9 -jcl:foun10 -Dverbose=true
-Xbootclasspath/p:c:/_work/p4/djdt1/wctme5.7/ive/lib/jdbc.jar
-Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource
-Dij.dataSource.databaseName=wombat
-Dij.dataSource.createDatabase=create
-Djvmflags=-Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource
-Dij.dataSource.databaseName=wombat
-Dij.dataSource.createDatabase=create
-Dbootcp=c:/_work/p4/djdt1/wctme5.7/ive/lib/jdbc.jar
org.apache.derbyTesting.functionTests.harness.RunSuite derbyall
Top suite: derbyall
NumberFormatException thrown trying to parse the version.
The test harness only handles the HP special case.
Now do RunList
Now run the suite's tests
Run the tests...
Exception in thread "main" java.lang.ClassNotFoundException:
org.apache.derbyTesting.functionTests.harness.jdk22
at java.lang.Class.forName(Class.java:116)
at org.apache.derbyTesting.functionTests.harness.jvm.getJvm(Unknown Source)
at
org.apache.derbyTesting.functionTests.harness.RunList.runTests(Unknown
Source)
at
org.apache.derbyTesting.functionTests.harness.RunList.runSuites(Unknown
Source)
at org.apache.derbyTesting.functionTests.harness.RunList.<init>(Unknown
Source)
at
org.apache.derbyTesting.functionTests.harness.RunSuite.getSuitesList(Unknown
Source)
at org.apache.derbyTesting.functionTests.harness.RunSuite.main(Unknown
Source)
Re: J9 Foundation & RunSuite
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Myrna van Lunteren wrote:
> The worst trouble in passing on properties is often between RunSuite and
> RunList...
> Which properties aren't being passed on, the bootclasspath? There's the
> -Dbootcp= flag that I hacked in specifically to enable the harness to
> pass on this special j9 jvmflag that do not fall in the -Xmx### format
> (so does not work with the jvmflags properties)...Or are the dataSource
> properties not getting passed on?
No, it's the properties I use to set the tests to obtain connections via
a DataSource through ij.
If I run RunTest directly with -Dij.dataSource=<dsclass> and other
ij.dataSource properties then everything is ok. RunTest sees these and
removes ij.database and ij.protocol from <test>_app property files.
But if I run RunSuite with the same -D flags, those properties are not
passed onto RunTest by RunSuite (RunList).
Dan.
Re: J9 Foundation & RunSuite
Posted by Myrna van Lunteren <m....@gmail.com>.
On 5/26/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> Myrna van Lunteren wrote:
>
> > Try the attached patch.
> Thanks that moves me further, now tests that pass when run with RunTest
> directly, fail when run in a suite. I think it's due to the way
> properties are (not) being passed.
:-(
Can you confirm something for me?
>
> When using RunTest directly another JVM is usually spawned to run the
> actual test. Ie.
>
> java org.apache.derbyTesting.functionTests.harness.RunTest <test>
> spawns another JVM to run the <test>
yes. Unless one of the properties you define is -Duseprocess=false, RunTest
does a Runtime.getRuntime().exec(cmd), which starts a subprocess.
In fact, before actually running that, it quickly do another
Runtime.getRuntime().exec to run sysinfo.
> From the verbose output of RunSuite, it seems RunSuite spawns a JVM to
> run RunTest which will then spawn a JVM to run the actual test, ie.
>
> java org.apache.derbyTesting.functionTests.harness.RunSuite <suite>
> spawns for each <test> in <suite>
> java org.apache.derbyTesting.functionTests.harness.RunTest <test>
> spawns another JVM to run the <test>
>
> Is this correct for RunSuite? I'd just assumed that RunSuite called
> RunTest directly as Java code.
No, from looking at the code, RunSuite actually calls RunList for every
subsuite and (unless you've got -Duseprocess=false set) RunList will kick
off it's own Runtime.getRuntime().exec(cmd) where cmd will be the command to
do <jvmexecutable> <properties>
org.apache.derbyTesting.functionTests.harness.RunTest <testname> for every
test.
So, without useprocess=false, you'll always have 3 processes running, one
for RunSuite, one for RunTest, and one for the actual test (e.g.
org.apache.derby.tools.ij or e.g.
org.apache.derbyTesting.functionTests.lang.closed).
The worst trouble in passing on properties is often between RunSuite and
RunList...
Which properties aren't being passed on, the bootclasspath? There's the
-Dbootcp= flag that I hacked in specifically to enable the harness to pass
on this special j9 jvmflag that do not fall in the -Xmx### format (so does
not work with the jvmflags properties)...Or are the dataSource properties
not getting passed on?
Could you possibly run with -Duseprocess=false? (I've not run the entire
derbyall that way, so there's probably some failures...)
Re: J9 Foundation & RunSuite
Posted by Andrew McIntyre <mc...@gmail.com>.
On May 26, 2005, at 12:17 PM, Daniel John Debrunner wrote:
> From the verbose output of RunSuite, it seems RunSuite spawns a JVM to
> run RunTest which will then spawn a JVM to run the actual test, ie.
>
> <snip>
>
> Is this correct for RunSuite? I'd just assumed that RunSuite called
> RunTest directly as Java code.
Wow. It's not RunSuite that's doing it, but RunList. See RunList:491.
Looking at the surrounding code, this is apparently a convoluted hack
to keep certain properties from being available to RunTest and/or
propagated back up to the RunSuite level. I don't think I ever noticed
this call to Runtime.exec() in RunList before now. This could obviously
be achieved in a drastically more efficient manner.
But, it's best not to get me started about all the things that are
wrong with RunList. Now I have another item to add to my list though.
:-P
andrew
Re: J9 Foundation & RunSuite
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Myrna van Lunteren wrote:
> Try the attached patch. I had failed to duplicate some code in RunSuite
> and had only duplicated it in RunList. Also making the check for
> 'foun10' rather than 'foun' in both RunList and RunSuite.java
Thanks that moves me further, now tests that pass when run with RunTest
directly, fail when run in a suite. I think it's due to the way
properties are (not) being passed.
Can you confirm something for me?
When using RunTest directly another JVM is usually spawned to run the
actual test. Ie.
java org.apache.derbyTesting.functionTests.harness.RunTest <test>
spawns another JVM to run the <test>
>From the verbose output of RunSuite, it seems RunSuite spawns a JVM to
run RunTest which will then spawn a JVM to run the actual test, ie.
java org.apache.derbyTesting.functionTests.harness.RunSuite <suite>
spawns for each <test> in <suite>
java org.apache.derbyTesting.functionTests.harness.RunTest <test>
spawns another JVM to run the <test>
Is this correct for RunSuite? I'd just assumed that RunSuite called
RunTest directly as Java code.
Thanks,
Dan.
Re: [PATCH] Pass ij.dataSource properties from RunList to RunTest WAS Re: J9 Foundation & RunSuite
Posted by Myrna van Lunteren <m....@gmail.com>.
As far as I can see this works fine.
However, I've been using my little props.java as a test, and there's a
DriverManager call in RunTest that is causing a problem at line 2311, which
with foundation of course gives a ClassNotFoundException, when running with
-Duseprocess=false.
It's only with .java tests, so e.g. the nist test suite would not suffer.
How do we get around that one - add another catch & ignore those, or...?
Myrna
On 5/30/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
>
> Andrew McIntyre wrote:
> > On 5/28/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> >
> >>Patch that makes RunList pass on any ij.dataSource properties in the
> >>System set to forked RunTest.
> >>
> >>This allows suites to be run using a datasource for the default
> >>connection instead of DriverManager. Allows testing of JSR169.
> >
> >
> > Haven't tested it yet, but it looks fine to me. Is there a reason to
> > enumerate the system properties instead of just using getProperty? Is
> > System.getProperty() missing from JSR169?
>
> The reason is that a number of properties are required to setup a
> connection using a data source and they all start with 'ij.dataSource'.
> And the exact names of the properties depends on the properties
> supported by the data source, thus the scheme needs to be flexible.
>
> Requires a single
> ij.dataSource=<class name of data source implementation>
>
> and then one or more of
>
> ij.dataSource.<property>=<value>
>
> where <property> is a Java Bean property of the DataSource implementation.
>
> Dan.
>
>
Re: [PATCH] Pass ij.dataSource properties from RunList to RunTest
WAS Re: J9 Foundation & RunSuite
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Andrew McIntyre wrote:
> On 5/28/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
>
>>Patch that makes RunList pass on any ij.dataSource properties in the
>>System set to forked RunTest.
>>
>>This allows suites to be run using a datasource for the default
>>connection instead of DriverManager. Allows testing of JSR169.
>
>
> Haven't tested it yet, but it looks fine to me. Is there a reason to
> enumerate the system properties instead of just using getProperty? Is
> System.getProperty() missing from JSR169?
The reason is that a number of properties are required to setup a
connection using a data source and they all start with 'ij.dataSource'.
And the exact names of the properties depends on the properties
supported by the data source, thus the scheme needs to be flexible.
Requires a single
ij.dataSource=<class name of data source implementation>
and then one or more of
ij.dataSource.<property>=<value>
where <property> is a Java Bean property of the DataSource implementation.
Dan.
Re: [PATCH] Pass ij.dataSource properties from RunList to RunTest WAS Re: J9 Foundation & RunSuite
Posted by Andrew McIntyre <mc...@gmail.com>.
On 5/28/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> Patch that makes RunList pass on any ij.dataSource properties in the
> System set to forked RunTest.
>
> This allows suites to be run using a datasource for the default
> connection instead of DriverManager. Allows testing of JSR169.
Haven't tested it yet, but it looks fine to me. Is there a reason to
enumerate the system properties instead of just using getProperty? Is
System.getProperty() missing from JSR169?
Jeremy - I think you will find this patch helpful for testing your
unified data source class. :-)
andrew
[PATCH] Pass ij.dataSource properties from RunList to RunTest WAS
Re: J9 Foundation & RunSuite
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Patch that makes RunList pass on any ij.dataSource properties in the
System set to forked RunTest.
This allows suites to be run using a datasource for the default
connection instead of DriverManager. Allows testing of JSR169.
When Derby moves to JUnit it should be a requirement that opening
Connection is cleanly separated from tests or the harness.
I'll commit this by Monday but would appreciate Andrew or Myrna (or
anyone else) having a look at it.
Thanks,
Dan.
Re: J9 Foundation & RunSuite
Posted by Myrna van Lunteren <m....@gmail.com>.
On 5/26/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> Myrna, your changes to RunTest for WCTME 5.7 (J9) enabled me to get it
> running with J9/JSR169 but RunSuite fails with errors parsing a version
> number. The version being parsed and causing the exception in
> JavaVersionHolder is
>
> J2ME Foundation Specification v1.0
>
> What should the field values be in JavaVersionHolder to match the
> changes you made in RunTest? (ie. minor, major version)
2 , 2.
The thing is, the test harness uses java.version and assumes it actually
gives the version. With j9, the java.version is not a number and it does not
well reflect the current version. So, instead, we need to switch to use
java.vm.version which for j9 gives more helpful details.
And does this mean that RunTest and RunSuite have separate mechanisms to
> determine the identity of a VM?
Well...I never said the test harness was pretty. :-)
Yes, RunTest and RunSuite both separately try to figure out what jvm is
running. That code is duplicated. And worse, RunList and RunSuite both do
the same thing also.
Try the attached patch. I had failed to duplicate some code in RunSuite and
had only duplicated it in RunList. Also making the check for 'foun10' rather
than 'foun' in both RunList and RunSuite.java
Of course, it really should be changed to pass the jvmversion on, hm?
(unless serverjvm is set to run networkserver in a different jvm).
Myrna
Re: J9 Foundation & RunSuite
Posted by scott hutinger <s-...@wiu.edu>.
It looks like JavaVersionHolder 'hack for special case' like in the
instance of looking for HP would work looking for 'J2ME'.
Although you more than likely already have had it working for a while,
and I'm sure a better method exists. :-)
scott
Daniel John Debrunner wrote:
>Myrna, your changes to RunTest for WCTME 5.7 (J9) enabled me to get it
>running with J9/JSR169 but RunSuite fails with errors parsing a version
>number. The version being parsed and causing the exception in
>JavaVersionHolder is
>
>J2ME Foundation Specification v1.0
>
>What should the field values be in JavaVersionHolder to match the
>changes you made in RunTest? (ie. minor, major version)
>
>And does this mean that RunTest and RunSuite have separate mechanisms to
>determine the identity of a VM?
>
>Thanks for any help,
>Dan.
>
>
>+ c:/_work/p4/djdt1/wctme5.7/ive/bin/j9 -jcl:foun10
>-Xbootclasspath/p:c:/_work/p4/djdt1/wctme5.7/ive/lib/jdbc.jar
>org.apache.derby.tools.sysinfo
>------------------ Java Information ------------------
>Java Version: J2ME Foundation Specification v1.0
>Java Vendor: IBM Corporation
>Java home: c:\_work\p4\djdt1\wctme5.7\ive
>Java classpath:
>c:/_work/svn/trunk/classes;c:/_work/svn/trunk/tools/java/jakarta-oro-2.0.8.jar
>OS name: Windows XP
>OS architecture: x86
>OS version: 5.1 build 2600 Service Pack 1
>Java user name: djd
>Java user home: C:\Documents and Settings\Administrator
>Java user dir: C:\_work\svn\trunk\systest\out
>java.specification.name: J2ME Foundation Specification
>java.specification.version: 1.0
>--------- Derby Information --------
>JRE - JDBC: J2ME - JDBC for CDC/FP 1.0
>[C:\_work\svn\trunk\classes] 10.1.0.0 alpha - (1)
>------------------------------------------------------
>----------------- Locale Information -----------------
>Current Locale : [English/United States [en_US]]
>Found support for locale: [de_DE]
> version: 10.1.0.0 alpha - (1)
>Found support for locale: [es]
> version: 10.1.0.0 alpha - (1)
>Found support for locale: [fr]
> version: 10.1.0.0 alpha - (1)
>Found support for locale: [it]
> version: 10.1.0.0 alpha - (1)
>Found support for locale: [ja_JP]
> version: 10.1.0.0 alpha - (1)
>Found support for locale: [ko_KR]
> version: 10.1.0.0 alpha - (1)
>Found support for locale: [pt_BR]
> version: 10.1.0.0 alpha - (1)
>Found support for locale: [zh_CN]
> version: 10.1.0.0 alpha - (1)
>Found support for locale: [zh_TW]
> version: 10.1.0.0 alpha - (1)
>------------------------------------------------------
>+ c:/_work/p4/djdt1/wctme5.7/ive/bin/j9 -jcl:foun10 -Dverbose=true
>-Xbootclasspath/p:c:/_work/p4/djdt1/wctme5.7/ive/lib/jdbc.jar
>-Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource
>-Dij.dataSource.databaseName=wombat
>-Dij.dataSource.createDatabase=create
>-Djvmflags=-Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource
>-Dij.dataSource.databaseName=wombat
>-Dij.dataSource.createDatabase=create
>-Dbootcp=c:/_work/p4/djdt1/wctme5.7/ive/lib/jdbc.jar
>org.apache.derbyTesting.functionTests.harness.RunSuite derbyall
>Top suite: derbyall
>NumberFormatException thrown trying to parse the version.
>The test harness only handles the HP special case.
>Now do RunList
>Now run the suite's tests
>Run the tests...
>Exception in thread "main" java.lang.ClassNotFoundException:
>org.apache.derbyTesting.functionTests.harness.jdk22
> at java.lang.Class.forName(Class.java:116)
> at org.apache.derbyTesting.functionTests.harness.jvm.getJvm(Unknown Source)
> at
>org.apache.derbyTesting.functionTests.harness.RunList.runTests(Unknown
>Source)
> at
>org.apache.derbyTesting.functionTests.harness.RunList.runSuites(Unknown
>Source)
> at org.apache.derbyTesting.functionTests.harness.RunList.<init>(Unknown
>Source)
> at
>org.apache.derbyTesting.functionTests.harness.RunSuite.getSuitesList(Unknown
>Source)
> at org.apache.derbyTesting.functionTests.harness.RunSuite.main(Unknown
>Source)
>
>
>
>