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 Michelle Caisse <Mi...@Sun.COM> on 2006/08/31 18:13:08 UTC
Running a Derby JUnit test using JUnit directly
Hi Dan, Susan,
I'm having trouble trying to run a Derby JUnit test outside of the
harness. I've tried three ways of running a test based on the example
and other information at
http://wiki.apache.org/db-derby/DerbyJUnitTesting and in
java/testing/README.htm. None works. Here's what I get:
[1]
c:/Program Files/Java/jdk1.6.0/bin/java -Djava.security.manager
-Djava.security.policy=derby_tests.policy
-Dderby.system.home=/cygdrive/c/derby/derby/qe/javasrc/webapps/jdbc4 -cp
c:/derby/derby/qe/javasrc/webapps/jdbc4//build/WEB-INF/classes/;c:/httpunit-1.6/lib/httpunit.jar;c:/db-derby-10.2.1.1/lib/derbyclient.jar;c:/db-derby-10.2.1.1/lib/derbynet.jar;c:/db-derby-10.2.1.1/lib/derby.jar;c:/db-derby-10.2.1.1/test/derbyTesting.jar;c:/junit3.8.1/junit.jar
junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest
Failed to invoke suite():java.lang.ExceptionInInitializerError
[2]
c:/Program Files/Java/jdk1.6.0/bin/java
-Dderby.system.home=/cygdrive/c/derby/derby/qe/javasrc/webapps/jdbc4 -cp
c:/derby/derby/qe/javasrc/webapps/jdbc4//build/WEB-INF/classes/;c:/httpunit-1.6/lib/httpunit.jar;c:/db-derby-10.2.1.1/lib/derbyclient.jar;c:/db-derby-10.2.1.1/lib/derbynet.jar;c:/db-derby-10.2.1.1/lib/derby.jar;c:/db-derby-10.2.1.1/test/derbyTesting.jar;c:/junit3.8.1/junit.jar
junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest
.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.EEE
Time: 6.594
There were 29 errors:
1)
testExecuteQueryWithNoDynamicResultSets(org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest)java.sql.SQLException:
Java exception: 'access denied (java.util.PropertyPermission user.dir
read): java.security.AccessControlException'.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
Source)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown
Source)
at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown
Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:185)
at
org.apache.derbyTesting.junit.TestConfiguration.openConnection(Unknown
Source)
at
org.apache.derbyTesting.junit.TestConfiguration.openDefaultConnection(Unknown
Source)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.openDefaultConnection(Unknown
Source)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.getConnection(Unknown Source)
at
org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest.setUp(Unknown
Source)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(Unknown
Source)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: java.sql.SQLException: Java exception: 'access denied
(java.util.PropertyPermission user.dir read):
java.security.AccessControlException'.
... 43 more
...
FAILURES!!!
Tests run: 27, Failures: 0, Errors: 29
[3]
c:/Program Files/Java/jdk1.6.0/bin/java -DnoSecurityManager=true
-Dderby.system.home=/cygdrive/c/derby/derby/qe/javasrc/webapps/jdbc4 -cp
c:/derby/derby/qe/javasrc/webapps/jdbc4//build/WEB-INF/classes/;c:/httpunit-1.6/lib/httpunit.jar;c:/db-derby-10.2.1.1/lib/derbyclient.jar;c:/db-derby-10.2.1.1/lib/derbynet.jar;c:/db-derby-10.2.1.1/lib/derby.jar;c:/db-derby-10.2.1.1/test/derbyTesting.jar;c:/junit
3.8.1/junit.jar junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest
.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.EEE
Time: 2.64
There were 29 errors:
1)
testExecuteQueryWithNoDynamicResultSets(org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest)java.sql.SQLException:
Java exception: 'access denied (java.util.PropertyPermission user.dir
read): java.security.AccessControlException'.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
Source)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown
Source)
at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown
Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:185)
at
org.apache.derbyTesting.junit.TestConfiguration.openConnection(Unknown
Source)
at
org.apache.derbyTesting.junit.TestConfiguration.openDefaultConnection(Unknown
Source)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.openDefaultConnection(Unknown
Source)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.getConnection(Unknown Source)
at
org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest.setUp(Unknown
Source)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(Unknown
Source)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: java.sql.SQLException: Java exception: 'access denied
(java.util.PropertyPermission user.dir read):
java.security.AccessControlException'.
... 43 more
Caused by: java.sql.SQLException: Java exception: 'access denied
(java.util.PropertyPermission user.dir read):
java.security.AccessControlException'.
... 28 more
FAILURES!!!
Tests run: 27, Failures: 0, Errors: 29
Any ideas?
Thanks,
Michelle
Re: Contribution of/repository for testing infrastructure tools (was
Re: Running a Derby JUnit test using JUnit directly)
Posted by Daniel John Debrunner <dj...@apache.org>.
Ole Solberg wrote:
> I will start by moving the scripts into my Derby sandbox, e.g. under
> tools/testing/reporting as suggested, and start the cleanup.
Great.
>
> I also have plans to make the failure analysis more "intelligent", but
> don't know yet how high on the priority list that ends up.
That's the point of making them open, you can throw out ideas and if you
can't get to them, maybe someone else can.
Thanks,
Dan.
Re: Contribution of/repository for testing infrastructure tools (was
Re: Running a Derby JUnit test using JUnit directly)
Posted by Ole Solberg <Ol...@Sun.COM>.
Ole Solberg wrote:
> Andrew McIntyre wrote:
>> On 9/6/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>>
>>>
>>> Actually I am curious about this tool and think maybe the tool itself
>>> and other testing infrastructure tools might really be great
>>> contribution to the community.
>>
>
> The internal tool we use for testing originated as a tool to handle HA
> database testing. It allows us to define test-rigs consisting of servers
> and clients, and run sets of tests on several test-rigs in parallel.
> Tests are defined in XML-files which essentially allow us to specify
> setups and teardowns, e.g. starting and stopping databases, and JUnit
> based test methods which are run from clients against the database(s).
> Results are reported to a test result database which eases creation of
> different kinds of test reports for testers, developers and managers.
>
>
> I am afraid this tool would need quite some work to be open-sourced.
> We would have to do both documentation and code cleanup, removing
> dependencies to other parts of our testing infrastructure, as well as
> resolution of legal issues. We would very much like to do this, but we
> do not have resources for it at the moment.
>
> The reporting scripts, which has already been donated in DERBY-812 in an
> earlier version, is a different thing. These are built for creating
> reports from the Derby test harness results and are independent of the
> rest of our testing infrastructure. We have also made some simple
> interfacing scripts to extract results from our internal test
> infrastructure tool into these reports.
>
>
>>
>> +10 - definitely would be a great contribution to the community. It
>> would allow for collaboration and enhancement of the scripts to make
>> testing easier for everyone in the community.
> Thanks!! That's nice to hear!
>
>>
>>> I am not sure exactly where these tools would be checked in, but are
>>> certainly worthy of a place.
>>
>>
>> Tools for testing should go somewhere under tools/testing. :-) Maybe
>> tools/testing/reporting or tools/testing/tinderbox (if applicable) or
>> something similar.
>>
>> I could check in the scripts from DERBY-812, but maybe there's a newer
>> version that's more worthy of being committed?
>
> The newer version of the reporting scripts which also attempts to do
> some failure analysis could in the short-term be uploaded as an update
> to DERBY-812.
> I would definitely like to put this into the repository so as to allow
> enhancements of the scripts by the community!
> Anyway, I would first like to go over them to generalize possible
> site-specific stuff which may have sneaked in.
>
> I will start by moving the scripts into my Derby sandbox, e.g. under
> tools/testing/reporting as suggested, and start the cleanup.
>
I have re-opened DERBY-812 and uploaded a patch with a newer,
cleaned-up, version of the scripts.
The new version goes into 'tools/testing/reporting/'.
The main difference since the previous version is the addition of
a simple failure analysis, and the possibility to create plots of
testsuite duration using gnuplot.
The patch contains README files explaining how to use the scripts.
>
> I also have plans to make the failure analysis more "intelligent", but
> don't know yet how high on the priority list that ends up.
>
>>
>> andrew
>
>
--
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway
Re: Contribution of/repository for testing infrastructure tools (was
Re: Running a Derby JUnit test using JUnit directly)
Posted by Ole Solberg <Ol...@Sun.COM>.
Andrew McIntyre wrote:
> On 9/6/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>
>>
>> Actually I am curious about this tool and think maybe the tool itself
>> and other testing infrastructure tools might really be great
>> contribution to the community.
>
The internal tool we use for testing originated as a tool to handle HA
database testing. It allows us to define test-rigs consisting of servers
and clients, and run sets of tests on several test-rigs in parallel.
Tests are defined in XML-files which essentially allow us to specify
setups and teardowns, e.g. starting and stopping databases, and JUnit
based test methods which are run from clients against the database(s).
Results are reported to a test result database which eases creation of
different kinds of test reports for testers, developers and managers.
I am afraid this tool would need quite some work to be open-sourced.
We would have to do both documentation and code cleanup, removing
dependencies to other parts of our testing infrastructure, as well as
resolution of legal issues. We would very much like to do this, but we
do not have resources for it at the moment.
The reporting scripts, which has already been donated in DERBY-812 in an
earlier version, is a different thing. These are built for creating
reports from the Derby test harness results and are independent of the
rest of our testing infrastructure. We have also made some simple
interfacing scripts to extract results from our internal test
infrastructure tool into these reports.
>
> +10 - definitely would be a great contribution to the community. It
> would allow for collaboration and enhancement of the scripts to make
> testing easier for everyone in the community.
Thanks!! That's nice to hear!
>
>> I am not sure exactly where these tools would be checked in, but are
>> certainly worthy of a place.
>
>
> Tools for testing should go somewhere under tools/testing. :-) Maybe
> tools/testing/reporting or tools/testing/tinderbox (if applicable) or
> something similar.
>
> I could check in the scripts from DERBY-812, but maybe there's a newer
> version that's more worthy of being committed?
The newer version of the reporting scripts which also attempts to do
some failure analysis could in the short-term be uploaded as an update
to DERBY-812.
I would definitely like to put this into the repository so as to allow
enhancements of the scripts by the community!
Anyway, I would first like to go over them to generalize possible
site-specific stuff which may have sneaked in.
I will start by moving the scripts into my Derby sandbox, e.g. under
tools/testing/reporting as suggested, and start the cleanup.
I also have plans to make the failure analysis more "intelligent", but
don't know yet how high on the priority list that ends up.
>
> andrew
--
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway
Re: Contribution of/repository for testing infrastructure tools (was Re: Running a Derby JUnit test using JUnit directly)
Posted by Andrew McIntyre <mc...@gmail.com>.
On 9/6/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>
> Actually I am curious about this tool and think maybe the tool itself
> and other testing infrastructure tools might really be great
> contribution to the community.
+10 - definitely would be a great contribution to the community. It
would allow for collaboration and enhancement of the scripts to make
testing easier for everyone in the community.
> I am not sure exactly where these tools would be checked in, but are
> certainly worthy of a place.
Tools for testing should go somewhere under tools/testing. :-) Maybe
tools/testing/reporting or tools/testing/tinderbox (if applicable) or
something similar.
I could check in the scripts from DERBY-812, but maybe there's a newer
version that's more worthy of being committed?
andrew
Re: Contribution of/repository for testing infrastructure tools
(was Re: Running a Derby JUnit test using JUnit directly)
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I second this, I really appreciate the latest test results being
posted. It would be nice if I could use these tools to quickly
look at test results from my own machine. It would be really helpful
to automatically know if an test failure is likely a known issue as
the current reports seem to automatically be able to determine.
Kathey Marsden wrote:
> Vemund Ostgaard wrote:
>
>> a tool that we use internally to distribute files to remote machines
>> for testing, and as such didn't seem interesting to the community.
>
>
> Actually I am curious about this tool and think maybe the tool itself
> and other testing infrastructure tools might really be great
> contribution to the community. We all benefit from the testing
> results of this the efficient QA efforts in Norway. I wonder might you
> consider contributing these tools so that they could be used in a more
> general purpose way and enhanced by all for the general benefit of the
> community?
>
> I am not sure exactly where these tools would be checked in, but are
> certainly worthy of a place. I recall that at one point a snapshot was
> made of the testing report scripts and then copied and forked for the
> IBM reports and then enhanced locally in Norway. Since they were not
> checked in, they they could not be enhanced open source style and used
> generally. I think if contributed, they could be enhanced ultimately it
> would be easy for anyone running tests to post them in the same format
> and link them off:
> http://db.apache.org/derby/derby_tests.html
>
> Kathey
>
>
>
>
>
>
>
>
>
Contribution of/repository for testing infrastructure tools (was
Re: Running a Derby JUnit test using JUnit directly)
Posted by Kathey Marsden <km...@sbcglobal.net>.
Vemund Ostgaard wrote:
> a tool that we use internally to distribute files to remote machines
> for testing, and as such didn't seem interesting to the community.
Actually I am curious about this tool and think maybe the tool itself
and other testing infrastructure tools might really be great
contribution to the community. We all benefit from the testing
results of this the efficient QA efforts in Norway. I wonder might you
consider contributing these tools so that they could be used in a more
general purpose way and enhanced by all for the general benefit of the
community?
I am not sure exactly where these tools would be checked in, but are
certainly worthy of a place. I recall that at one point a snapshot was
made of the testing report scripts and then copied and forked for the
IBM reports and then enhanced locally in Norway. Since they were not
checked in, they they could not be enhanced open source style and used
generally. I think if contributed, they could be enhanced ultimately it
would be easy for anyone running tests to post them in the same format
and link them off:
http://db.apache.org/derby/derby_tests.html
Kathey
Re: Running a Derby JUnit test using JUnit directly
Posted by Vemund Ostgaard <Ve...@Sun.COM>.
Daniel John Debrunner wrote:
>Vemund Ostgaard wrote:
>
>
>
>>For the jobs doing nightly testing on the 10.2 branch we did a short
>>term workaround by copying derbyTesting.jar to its old location, to
>>avoid other changes. So, thats why it hasn't failed in those tests.
>>
>>
>
>It's good to report such problems, not just work-around them. That way
>others get to know and the issue can be fixed quicker.
>
>Or maybe I missed the e-mail discussing this?
>
Yes, I agree. The problem we had though was with a tool that we use
internally to distribute files to remote machines for testing, and as
such didn't seem interesting to the community. We didn't check if the
problem hid other problems that were relevant for the community, which
evidently was the case.
Vemund
Re: test/lib split in distribution - WAS Re: Running a Derby JUnit test using JUnit directly
Posted by Myrna van Lunteren <m....@gmail.com>.
On 9/1/06, Daniel John Debrunner <dj...@apache.org> wrote:
> Myrna van Lunteren wrote:
>
> > On 9/1/06, Daniel John Debrunner <dj...@apache.org> wrote:
> >
> >
[snip]
> > Now that we know of the problem, I have to say I prefer the jumble
> > approach, especially when the need arises to run on a number of
> > different machines.
>
> Why? Just trying to understand why you prefer it, you say you do but
> provide no reason why. :-) Kind of like a veto with no reason!
Apologies, I didn't imply to veto anything. I like the jumble of
course because of habit, but I find it convenient and logical when
having to run derbyall on a number of rarely used machines, to have
all derby*.jar of a specific version and jars in one dir, one level
deep, with a nice breezy dir name like '102b1'. Also when using
scripts and copying jars around it's just easy to use the derby*.jar.
It's really no big deal though.
>
[snip]
test/lib split in distribution - WAS Re: Running a Derby JUnit test
using JUnit directly
Posted by Daniel John Debrunner <dj...@apache.org>.
Myrna van Lunteren wrote:
> On 9/1/06, Daniel John Debrunner <dj...@apache.org> wrote:
>
>> Vemund Ostgaard wrote:
>>
>> > For the jobs doing nightly testing on the 10.2 branch we did a short
>> > term workaround by copying derbyTesting.jar to its old location, to
>> > avoid other changes. So, thats why it hasn't failed in those tests.
>>
>> It's good to report such problems, not just work-around them. That way
>> others get to know and the issue can be fixed quicker.
>>
>> Or maybe I missed the e-mail discussing this?
>> Dan.
>>
>>
> This is a good catch - I had just continued my practice from earlier
> versions to copy all derby*.jar files to one location and set my own
> classpath, I never thought about verifying with the split set-up.
>
> I think the harness/policyfile should work either way...
The changes I'm making will make that so.
>
> Now that we know of the problem, I have to say I prefer the jumble
> approach, especially when the need arises to run on a number of
> different machines.
Why? Just trying to understand why you prefer it, you say you do but
provide no reason why. :-) Kind of like a veto with no reason!
The reason I entered the improvement to have the split was so that users
of Derby who want to re-distribute it will have a clear separation as to
what was needed for the database "product" code and what was for the
tests. This becomes increasingly important in the future as more
non-derby jars are shipped with Derby, e.g. I could see in the future
having (assuming licencing is ok for any jar):
- lucene jar for text indexing
- oro jar for the harness (done today in test)
- junit jar
- apache commons jar to pick up soundex code
I believe that if all of these are lumped in lib or even lib/3rdparty
then it's really unclear which are just needed for the tests, and the
default action will be someone to ship all of it, and then complain
about the footprint.
I also believe that there should be a very easy setup for users to run
all the tests, something like the derbyrun we have today for ij etc. So
that any one can run the derby tests from a distribution doing something
like:
java -jar test/derbyTesting.jar
This ties into the split as it obviously requires Derby distribution to
contain all the jars required by the test runs.
This would be a default test setup run, the "common case", it would not
cater for all situations, such as the remote host running you do, or
testing running the 10.2 tests against 10.3, which are important but
less likely for users of Derby to do.
Thanks,
Dan.
Re: Running a Derby JUnit test using JUnit directly
Posted by "Susan L. Cline" <ho...@pacbell.net>.
--- Daniel John Debrunner <dj...@apache.org> wrote:
> Susan L. Cline wrote:
>
>
> > [ snip]
> >
> > I'm still trying to figure out if there is a way to run a JUnit test standalone
> > against the jars. What I am trying to do is to test the 10.2 beta release using
> > a derbyTesting.jar I built in the development branch (10.3). I'm trying to use the
> > class I created to test the functionality of something in the 10.2 beta release
> > without having to check out the 10.2 branch(trunk? sorry I don't know the terminology
> > here.)
>
> That's cutting edge technology :-)
>
> The JUnit work for running tests standalone is a work in progress, I'm
> working in the trunk, Rick has been merging changes up to 10.2 but I
> haven't looked to see what state those changes are in the 10.2 branch
> and the beta release.
>
[snip]
>
> If this test is for submission to Derby the best thing to do is to
> contribute it for the trunk and then it will be merged up to the branch
> and become part of the 10.2 standard tests.
>
> Thanks,
> Dan.
Okay, thanks Dan. That is what I have done created the patch against the trunk,
so I'll consider this task complete.
Thanks,
Susan
Re: Running a Derby JUnit test using JUnit directly
Posted by Daniel John Debrunner <dj...@apache.org>.
Susan L. Cline wrote:
> [ snip]
>
> I'm still trying to figure out if there is a way to run a JUnit test standalone
> against the jars. What I am trying to do is to test the 10.2 beta release using
> a derbyTesting.jar I built in the development branch (10.3). I'm trying to use the
> class I created to test the functionality of something in the 10.2 beta release
> without having to check out the 10.2 branch(trunk? sorry I don't know the terminology
> here.)
That's cutting edge technology :-)
The JUnit work for running tests standalone is a work in progress, I'm
working in the trunk, Rick has been merging changes up to 10.2 but I
haven't looked to see what state those changes are in the 10.2 branch
and the beta release.
I think the only requirement for 10.2 is that derbyall continues to run
successfully, I think it would be great if 10.2 and trunk were identical
in their Junit setup but that may not happen until after the first GA
release.
If this test is for submission to Derby the best thing to do is to
contribute it for the trunk and then it will be merged up to the branch
and become part of the 10.2 standard tests.
Thanks,
Dan.
Re: Running a Derby JUnit test using JUnit directly
Posted by "Susan L. Cline" <ho...@pacbell.net>.
--- Myrna van Lunteren <m....@gmail.com> wrote:
> On 9/1/06, Daniel John Debrunner <dj...@apache.org> wrote:
> > Vemund Ostgaard wrote:
> >
> > > For the jobs doing nightly testing on the 10.2 branch we did a short
> > > term workaround by copying derbyTesting.jar to its old location, to
> > > avoid other changes. So, thats why it hasn't failed in those tests.
> >
> > It's good to report such problems, not just work-around them. That way
> > others get to know and the issue can be fixed quicker.
> >
> > Or maybe I missed the e-mail discussing this?
> > Dan.
> >
> >
> This is a good catch - I had just continued my practice from earlier
> versions to copy all derby*.jar files to one location and set my own
> classpath, I never thought about verifying with the split set-up.
>
> I think the harness/policyfile should work either way...
>
[ snip]
I'm still trying to figure out if there is a way to run a JUnit test standalone
against the jars. What I am trying to do is to test the 10.2 beta release using
a derbyTesting.jar I built in the development branch (10.3). I'm trying to use the
class I created to test the functionality of something in the 10.2 beta release
without having to check out the 10.2 branch(trunk? sorry I don't know the terminology
here.)
So here's what I have;
lib directory with all of the derby jar files from the 10.2 release EXCEPT the derbyTesting.jar
I copied over the derbyTesting.jar I created from the 10.3 trunk to the lib directory
I've tried various combinations / permutations of running my JUnit test standalone and can not
succeed. The wiki entry, http://wiki.apache.org/db-derby/DerbyJUnitTesting, says,
'The classpath needs to include the junit.jar and the Derby classes.'
So is there anyway to run it just using the jar files and not the classes directory?
Some of the things I've tried are including the derby.system.home on the command line and
having a derby_tests.policy file in derby home, and not having the derby_tests.policy file
in derby.system.home. I've passed the classpath on the command line, and set it as an
environment variable - sometimes I get 'NO SUITABLE DRIVER' errors, other times I don't.
Thanks,
Susan
Re: Running a Derby JUnit test using JUnit directly
Posted by Myrna van Lunteren <m....@gmail.com>.
On 9/1/06, Daniel John Debrunner <dj...@apache.org> wrote:
> Vemund Ostgaard wrote:
>
> > For the jobs doing nightly testing on the 10.2 branch we did a short
> > term workaround by copying derbyTesting.jar to its old location, to
> > avoid other changes. So, thats why it hasn't failed in those tests.
>
> It's good to report such problems, not just work-around them. That way
> others get to know and the issue can be fixed quicker.
>
> Or maybe I missed the e-mail discussing this?
> Dan.
>
>
This is a good catch - I had just continued my practice from earlier
versions to copy all derby*.jar files to one location and set my own
classpath, I never thought about verifying with the split set-up.
I think the harness/policyfile should work either way...
Now that we know of the problem, I have to say I prefer the jumble
approach, especially when the need arises to run on a number of
different machines.
Myrna
Re: Running a Derby JUnit test using JUnit directly
Posted by Daniel John Debrunner <dj...@apache.org>.
Vemund Ostgaard wrote:
> For the jobs doing nightly testing on the 10.2 branch we did a short
> term workaround by copying derbyTesting.jar to its old location, to
> avoid other changes. So, thats why it hasn't failed in those tests.
It's good to report such problems, not just work-around them. That way
others get to know and the issue can be fixed quicker.
Or maybe I missed the e-mail discussing this?
Dan.
Re: Running a Derby JUnit test using JUnit directly
Posted by Vemund Ostgaard <Ve...@Sun.COM>.
Daniel John Debrunner wrote:
>Michelle Caisse wrote:
>
>
>
>>>>I was using 10.2.1.1.
>>>>
>>>>
>
>I see the same failure as you.
>
>It's because the policy file is not setup to handle derbyTesting.jar
>being in a different folder to derby.jar etc.
>
>It's actually nothing to do with JUnit, you will see problems running
>tests with the old harness.
>
>I'm very suprised no-one has seen this before, since I thought there
>have been several reports of derbyall passing against 10.2.1.1.
>
>
For the jobs doing nightly testing on the 10.2 branch we did a short
term workaround by copying derbyTesting.jar to its old location, to
avoid other changes. So, thats why it hasn't failed in those tests.
Vemund
Re: Running a Derby JUnit test using JUnit directly
Posted by Daniel John Debrunner <dj...@apache.org>.
Michelle Caisse wrote:
>>> I was using 10.2.1.1.
I see the same failure as you.
It's because the policy file is not setup to handle derbyTesting.jar
being in a different folder to derby.jar etc.
It's actually nothing to do with JUnit, you will see problems running
tests with the old harness.
I'm very suprised no-one has seen this before, since I thought there
have been several reports of derbyall passing against 10.2.1.1.
Dan.
Re: Running a Derby JUnit test using JUnit directly
Posted by Michelle Caisse <Mi...@Sun.COM>.
Daniel John Debrunner wrote:
>Michelle Caisse wrote:
>
>
>
>
>>I was using 10.2.1.1. Does the current reality require building from
>>the latest source?
>>
>>
>
>Possibly, that's my itch. I haven't been keeping careful track of where
>the 10.2 line is relative to trunk.
>
>I think though that 10.2 should work if you remove the security manager
>stuff. One question though, did you copy the policy file into the
>current directory?
>
>Dan.
>
>
>
Yes. I also tried running without the security manager flags. It's one
of the three invocations I originally tried.
I will download a nightly build and try this.
-- Michelle
Re: Running a Derby JUnit test using JUnit directly
Posted by Daniel John Debrunner <dj...@apache.org>.
Michelle Caisse wrote:
> I was using 10.2.1.1. Does the current reality require building from
> the latest source?
Possibly, that's my itch. I haven't been keeping careful track of where
the 10.2 line is relative to trunk.
I think though that 10.2 should work if you remove the security manager
stuff. One question though, did you copy the policy file into the
current directory?
Dan.
Re: Running a Derby JUnit test using JUnit directly
Posted by Michelle Caisse <Mi...@Sun.COM>.
Daniel John Debrunner wrote:
>Daniel John Debrunner wrote:
>
>
>
>>Michelle Caisse wrote:
>>
>>
>>
>>
>>>Hi Dan, Susan,
>>>
>>>I'm having trouble trying to run a Derby JUnit test outside of the
>>>harness. I've tried three ways of running a test based on the example
>>>and other information at
>>>http://wiki.apache.org/db-derby/DerbyJUnitTesting and in
>>>java/testing/README.htm. None works. Here's what I get:
>>>
>>>
>>
>>
>>>c:/Program Files/Java/jdk1.6.0/bin/java -Djava.security.manager -Djava.security.policy=derby_tests.policy -Dderby.system.home=/cygdrive/c/derby/derby/qe/javasrc/webapps/jdbc4 -cp c:/derby/derby/qe/javasrc/webapps/jdbc4//build/WEB-INF/classes/;c:/httpunit-1.6/lib/httpunit.jar;c:/db-derby-10.2.1.1/lib/derbyclient.jar;c:/db-derby-10.2.1.1/lib/derbynet.jar;c:/db-derby-10.2.1.1/lib/derby.jar;c:/db-derby-10.2.1.1/test/derbyTesting.jar;c:/junit3.8.1/junit.jar junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest
>>>
>>>
>>Try removing the -Djava.security.manager and
>>-Djava.security.policy=derby_tests.policy
>>
>>I was just about to update the wiki section about running Derby JUnit tests.
>>
>>
>
>I've updated this page to refect currently reality, can you see if you
>follow it if you are successful.
>
>http://wiki.apache.org/db-derby/DerbyJUnitTesting
>
>Thanks,
>Dan.
>
>
>
I was using 10.2.1.1. Does the current reality require building from
the latest source?
-- Michelle
Re: Running a Derby JUnit test using JUnit directly
Posted by Daniel John Debrunner <dj...@apache.org>.
Daniel John Debrunner wrote:
> Michelle Caisse wrote:
>
>
>>Hi Dan, Susan,
>>
>>I'm having trouble trying to run a Derby JUnit test outside of the
>>harness. I've tried three ways of running a test based on the example
>>and other information at
>>http://wiki.apache.org/db-derby/DerbyJUnitTesting and in
>>java/testing/README.htm. None works. Here's what I get:
>
>
>>c:/Program Files/Java/jdk1.6.0/bin/java -Djava.security.manager -Djava.security.policy=derby_tests.policy -Dderby.system.home=/cygdrive/c/derby/derby/qe/javasrc/webapps/jdbc4 -cp c:/derby/derby/qe/javasrc/webapps/jdbc4//build/WEB-INF/classes/;c:/httpunit-1.6/lib/httpunit.jar;c:/db-derby-10.2.1.1/lib/derbyclient.jar;c:/db-derby-10.2.1.1/lib/derbynet.jar;c:/db-derby-10.2.1.1/lib/derby.jar;c:/db-derby-10.2.1.1/test/derbyTesting.jar;c:/junit3.8.1/junit.jar junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest
>
>
> Try removing the -Djava.security.manager and
> -Djava.security.policy=derby_tests.policy
>
> I was just about to update the wiki section about running Derby JUnit tests.
I've updated this page to refect currently reality, can you see if you
follow it if you are successful.
http://wiki.apache.org/db-derby/DerbyJUnitTesting
Thanks,
Dan.
Re: Running a Derby JUnit test using JUnit directly
Posted by Daniel John Debrunner <dj...@apache.org>.
Michelle Caisse wrote:
> Hi Dan, Susan,
>
> I'm having trouble trying to run a Derby JUnit test outside of the
> harness. I've tried three ways of running a test based on the example
> and other information at
> http://wiki.apache.org/db-derby/DerbyJUnitTesting and in
> java/testing/README.htm. None works. Here's what I get:
> c:/Program Files/Java/jdk1.6.0/bin/java -Djava.security.manager -Djava.security.policy=derby_tests.policy -Dderby.system.home=/cygdrive/c/derby/derby/qe/javasrc/webapps/jdbc4 -cp c:/derby/derby/qe/javasrc/webapps/jdbc4//build/WEB-INF/classes/;c:/httpunit-1.6/lib/httpunit.jar;c:/db-derby-10.2.1.1/lib/derbyclient.jar;c:/db-derby-10.2.1.1/lib/derbynet.jar;c:/db-derby-10.2.1.1/lib/derby.jar;c:/db-derby-10.2.1.1/test/derbyTesting.jar;c:/junit3.8.1/junit.jar junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest
Try removing the -Djava.security.manager and
-Djava.security.policy=derby_tests.policy
I was just about to update the wiki section about running Derby JUnit tests.
Dan.