Hi Lashan,
I am unable to reproduce the behavior you are seeing. The tests start
running when I wire those code sources into a CLASSPATH and execute that
java command. Can you include the output from the following command:
echo $CLASSPATH
Thanks,
-Rick
On 8/16/17 6:19 AM, Lashan Faliq wro
I have set $CLASSPATH to include the following jars:
• derbyTesting.jar
• derbyrun.jar
• junit.jar
• trunk/classes
still when I run
java org.apache.derbyTesting.functionTests.harness.RunSuite derbyall
I get the error
Error: Could not find or load main class
org.apache.derbyTesting.function
://builds.apache.org/job/Derby-jacoco/ was successful.
Closing the issue.
> Failures when running tests with JaCoCo
> ---
>
> Key: DERBY-6697
> URL: https://issues.apache.org/jira/browse/DERBY-6697
> Project: Derb
mmit 1617240 from [~knutanders] in branch 'code/trunk'
[ https://svn.apache.org/r1617240 ]
DERBY-6697: Failures when running tests with JaCoCo
Add permissions needed by JaCoCo to MissingPermissionTest's custom
policy file.
Make BaseTestCase.execJavaCmd() propagate the empty jacoco
without JaCoCo.
> Failures when running tests with JaCoCo
> ---
>
> Key: DERBY-6697
> URL: https://issues.apache.org/jira/browse/DERBY-6697
> Project: Derby
> Issue Type: Bug
>
when the tests run
under JaCoCo. This is too broad, and DBOAccessTest doesn't get the
AccessControlException it expects. Instead, it fails with another exception
further down the road.
> Failures when running tests with JaCoCo
> ---
>
>
[
https://issues.apache.org/jira/browse/DERBY-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen reassigned DERBY-6697:
-
Assignee: Knut Anders Hatlen
> Failures when running tests with JaC
st JaCoCo version (0.7.1).
> Failures when running tests with JaCoCo
> ---
>
> Key: DERBY-6697
> URL: https://issues.apache.org/jira/browse/DERBY-6697
> Project: Derby
> Issue Type: B
Knut Anders Hatlen created DERBY-6697:
-
Summary: Failures when running tests with JaCoCo
Key: DERBY-6697
URL: https://issues.apache.org/jira/browse/DERBY-6697
Project: Derby
Issue Type
Hi,
You're not the first to trip over our slow progress of moving to junit.
The README.htm belonged to the old harness of master-based tests.
We've been slowly converting tests to junit, and usually new tests are
written in junit. engine/ErrorStreamTest is a junit test.
For instructions on ho
I am trashing about trying to figure out how to correctly run the tests after
building the trunk code. I want to run the engine/ErrorStreamTest as a single
test. How do I go about doing that?
I followed the procedure on
http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/README.htm?
.
> NoClassDefFoundErrors when running tests without derbynet.jar and
> derbyclient.jar
> -
>
> Key: DERBY-5917
> URL: https://issues.apache.org/jira
spath).
> NoClassDefFoundErrors when running tests without derbynet.jar and
> derbyclient.jar
> -
>
> Key: DERBY-5917
> URL: https://issues.apache.org/jira/browse/DERBY-591
est fails because it checks if the connection is a
client.am.Connection instance in order to find out if it's running with the
client.
> NoClassDefFoundErrors when running tests without derbynet.jar and
2032.
> NoClassDefFoundErrors when running tests without derbynet.jar and
> derbyclient.jar
> -
>
> Key: DERBY-5917
> URL: https://issues.apache.org/
sion suite (with
client/server jars).
> NoClassDefFoundErrors when running tests without derbynet.jar and
> derbyclient.jar
> -
>
> Key: DERBY-5917
> UR
Knut Anders Hatlen created DERBY-5917:
-
Summary: NoClassDefFoundErrors when running tests without
derbynet.jar and derbyclient.jar
Key: DERBY-5917
URL: https://issues.apache.org/jira/browse/DERBY-5917
1242294.
> Prepare old test harness for running tests on Java 8
>
>
> Key: DERBY-5609
> URL: https://issues.apache.org/jira/browse/DERBY-5609
> Project: Derby
>
backport the fix to 10.8.
> Prepare old test harness for running tests on Java 8
>
>
> Key: DERBY-5609
> URL: https://issues.apache.org/jira/browse/DERBY-5609
>
ssing.
> Prepare old test harness for running tests on Java 8
>
>
> Key: DERBY-5609
> URL: https://issues.apache.org/jira/browse/DERBY-5609
> Project: Derby
>
Prepare old test harness for running tests on Java 8
Key: DERBY-5609
URL: https://issues.apache.org/jira/browse/DERBY-5609
Project: Derby
Issue Type: Improvement
Components
this file, sections 1 onwards apply to running tests using the old harness
which still applies to a significant number of tests. Currently to run the
complete set of tests two runs are required, run the harness based tests
decribed in this document and then running all the JUnit bases tests.
I
This is a comment from build.xml, maybe it will help:
In my case, I am able to run "ant junit-all" without any setting in my
CLASSPATH after building with "ant all buildjars".
Dag
Hi Brett,
You can also run the tests outside of ant. Here's what I do:
1) Set up my classpath to include the following:
- the jars in tools/java (including the junit jar)
- the derby jars which I have built
- the xalan jars
2) Then issue the following command:
java -XX:MaxPermSize=12
I am trying to run the current test using the ant target "junit-all", but all
tests fail. Obviously I have not setup something in my environment. For
example in one test, I see the following:
java.lang.ClassNotFoundException:
org.apache.derbyTesting.functionTests.tests.demo._Suite
at
Thanks, all, the recommended settings worked for me.
/mikem
Dag H. Wanvik wrote:
Bryan Pendleton writes:
Are there any test specific settings, or recommended size settings?
My current Ubuntu magic incantation is:
java org.apache.derbyTesting.functionTests.harness.RunSuite derbyall;
java -Xm
Bryan Pendleton writes:
>> Are there any test specific settings, or recommended size settings?
>
> My current Ubuntu magic incantation is:
>
> java org.apache.derbyTesting.functionTests.harness.RunSuite derbyall;
> java -Xmx512m -XX:MaxPermSize=128m junit.textui.TestRunner
FWIW, I use the same s
Are there any test specific settings, or recommended size settings?
My current Ubuntu magic incantation is:
java org.apache.derbyTesting.functionTests.harness.RunSuite derbyall; java -Xmx512m -XX:MaxPermSize=128m junit.textui.TestRunner
org.apache.derbyTesting.functionTests.suites.All >junitAl
Hi Mike,
Try like this
java -Xmx512m
-XX:MaxPermSize=128morg.apache.derbyTesting.functionTests.harness.RunSuite
derbyall
Hope this help.
On Mon, Jun 28, 2010 at 10:14 PM, Mike Matrigali wrote:
> I am setting up an ubuntu environment. I am just trying to get
> a clean nightly run on trunk wi
I am setting up an ubuntu environment. I am just trying to get
a clean nightly run on trunk with no changes. So far I keep running
out of memory in
the test in the junit run. The machine has plenty - almost 4 gig.
I tried bumpting the Mx but still ran of permspace? I tried
bumping -XX:MaxPerm
ersion running tests via ant
>
>
> Key: DERBY-3148
> URL: https://issues.apache.org/jira/browse/DERBY-3148
> Project: Derby
>
le trying to find
> Xalan version running tests via ant
>
>
> Key: DERBY-3148
> URL: https://issues.apache.org/jira/browse/DERBY-3148
&
ion: Malformed \u encoding while trying to find
> Xalan version running tests via ant
>
>
> Key: DERBY-3148
> URL: https://issues.apache.org/jira
your suggestions. There is still a chance for failure if the a user has
"version.xalan2_2=" in his/her classpath, but this is hopefully an improvement
over the current behavior...
> IllegalArgumentException: Malformed \u encoding while trying to find
> Xalan version
ot;) [note the equals] would be
safer?
> IllegalArgumentException: Malformed \u encoding while trying to find
> Xalan version running tests via ant
>
>
>
default encoding of the
platform, and then read using ISO-8859-1.
Whichever encoding is used, it needs to be consistent on read and write.
> IllegalArgumentException: Malformed \u encoding while trying to find
> Xalan version running tests v
up
in the classpath, that'll fail, too.
> IllegalArgumentException: Malformed \u encoding while trying to find
> Xalan version running tests via ant
>
>
>
Properties and instead just does a plain old string search for the
line containing the target property. This seems to have solved the problem...
Is this too naive of a solution?
> IllegalArgumentException: Malformed \u encoding while trying to find
> Xalan version running tests v
ion: Malformed \u encoding while trying to find
> Xalan version running tests via ant
>
>
> Key: DERBY-3148
> URL: https://issues.apache.org
ath (on windows) has elements which
include '\utils' which Properties.load is trying to interpret as a unicode
escape sequence (\u).
> IllegalArgumentException: Malformed \u encoding while trying to find
>
IllegalArgumentException: Malformed \u encoding while trying to find Xalan
version running tests via ant
Key: DERBY-3148
URL: https
[
https://issues.apache.org/jira/browse/DERBY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myrna van Lunteren updated DERBY-2269:
--
Component/s: Test
> running tests (derbyall, or suites.All) with weme6.1 (or wctme
[
https://issues.apache.org/jira/browse/DERBY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myrna van Lunteren closed DERBY-2269.
-
Resolution: Fixed
> running tests (derbyall, or suites.All) with weme6.1 (or wctme
[
https://issues.apache.org/jira/browse/DERBY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myrna van Lunteren reopened DERBY-2269:
---
> running tests (derbyall, or suites.All) with weme6.1 (or wctme5.7) w
revision 501337:
http://svn.apache.org/viewvc?view=rev&revision=501337
> running tests (derbyall, or suites.All) with weme6.1 (or wctme5.7) with
> derbyrun.jar fails with NoClassDefFoundError: javax.naming.Ref
wrong because it will mask situations where the class can not be
loaded due to a bug. E.g. ClientDataSource depends on a class in derbytools.jar.
> running tests (derbyall, or suites.All) with weme6.1 (or wctme5.7) with
> derbyrun.jar fails with NoClassDefFoundError: javax.naming.Referen
[
https://issues.apache.org/jira/browse/DERBY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myrna van Lunteren updated DERBY-2269:
--
Derby Info: [Patch Available]
> running tests (derbyall, or suites.All) with weme
ting in loading
of javax.naming.Referenceable down the line.
I'd like input on which approach is preferable.
Once I get that, I'll (re)run derbyall & suites.All. If I don't get any input,
I'll go with approach b.
> running tests (derbyall, or suites.All) with weme6.
[
https://issues.apache.org/jira/browse/DERBY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myrna van Lunteren reassigned DERBY-2269:
-
Assignee: Myrna van Lunteren
> running tests (derbyall, or suites.All) w
running tests (derbyall, or suites.All) with weme6.1 (or wctme5.7) with
derbyrun.jar fails with NoClassDefFoundError: javax.naming.Referenceable
10.2 with revision 499604. (See:
http://svn.apache.org/viewvc?view=rev&revision=499604).
> QuickStart section of java/testing/README.htm should contain Sun JDK6 as
> supported java version for run
. Here's a .diff reflecting the adding of
jdk16, and ibm15 jvms as supported jvms. (was already true, now also
documented).
> QuickStart section of java/testing/README.htm should contain Sun JDK6 as
> supported java version for ru
.
> QuickStart section of java/testing/README.htm should contain Sun JDK6 as
> supported java version for running tests
> -
>
> Key: DERBY-2184
>
htm should contain Sun JDK6 as
> supported java version for running tests
> -
>
> Key: DERBY-2184
> URL: https://issues.apache.org/jira
.
> QuickStart section of java/testing/README.htm should contain Sun JDK6 as
> supported java version for running tests
> -
>
> Key: DERBY-2184
>
htm should contain Sun JDK6 as
> supported java version for running tests
> -
>
> Key: DERBY-2184
> URL: https://issues.apache.org/jira
QuickStart section of java/testing/README.htm should contain Sun JDK6 as
supported java version for running tests
-
Key: DERBY-2184
URL: http
I would recommend trying to determine what
value running the test in a different environment has. If the same test
cases work and pass in both modes then probably no additional testing
resulted due to the run in SQL authorization mode.
I'm not sure I agree with that totally; I think I would sa
Bryan Pendleton wrote:
During the review for DERBY-1490, several reviewers noted that it would
be useful to be able to run various tests in two configurations:
- with sqlAuthorization=true
- with sqlAuthorization=false
A good example of this is the test suite lang/altertable.sql, which
current
During the review for DERBY-1490, several reviewers noted that it would
be useful to be able to run various tests in two configurations:
- with sqlAuthorization=true
- with sqlAuthorization=false
A good example of this is the test suite lang/altertable.sql, which
currently runs with sqlAuthoriz
[ http://issues.apache.org/jira/browse/DERBY-1941?page=all ]
James F. Adams updated DERBY-1941:
--
Derby Info: [Patch Available]
> CLASSPATH in 2.1 running tests section of test\README.htm should contain
> derbyr
[ http://issues.apache.org/jira/browse/DERBY-1941?page=all ]
James F. Adams updated DERBY-1941:
--
Attachment: readme.patch.txt
I have uploaded a patch that modifies the file java/testing/README.htm.
> CLASSPATH in 2.1 running tests section of t
[ http://issues.apache.org/jira/browse/DERBY-1941?page=all ]
James F. Adams reassigned DERBY-1941:
-
Assignee: James F. Adams
> CLASSPATH in 2.1 running tests section of test\README.htm should contain
> derbyr
CLASSPATH in 2.1 running tests section of test\README.htm should contain
derbyrun.jar
-
Key: DERBY-1941
URL: http://issues.apache.org/jira/browse/DERBY-1941
Project
On 7/19/06, Army <[EMAIL PROTECTED]> wrote:
Deepa Remesh wrote:
>
> I tried running a test with derbytools.jar preceding derby.jar in the
> classpath and I see the same exception.
Thank you for confirming this behavior, Deepa. I filed DERBY-1537 for this
problem.
I also ran into this problem
Deepa Remesh wrote:
I tried running a test with derbytools.jar preceding derby.jar in the
classpath and I see the same exception.
Thank you for confirming this behavior, Deepa. I filed DERBY-1537 for this
problem.
Army
On 7/19/06, Army <[EMAIL PROTECTED]> wrote:
Can anyone else reproduce this behavior, or do I have something amiss in my
environment?
If this is not just my problem, I'll file a Jira issue for it...
I tried running a test with derbytools.jar preceding derby.jar in the
classpath and I see the s
I'm trying to run derbyall against sane jars built from a *clean* codeline. I
have a script to set up the classpath and that script just happens to put
derbytools.jar before derby.jar in my classpath. I didn't think this would be a
big deal...
It turns out that when derbytools.jar precedes d
John Embretsen wrote:
Myrna van Lunteren wrote:
-Djvmflags will do anything for NetworkServerControl, it only works
with the test harness
(org.apache.derbyTesting.functionTests.harness.RunTest or RunSuite).
That is true.
A "not" is missing from Myrna's statement above. What I meant to say w
clienttracing.html.
I was not able to see any mention of such properties on the server side.
And they had no effect when I tried them...
To enable server side tracing, I found it easiest to follow the approach
described by Knut Anders in
http://www.nabble.com/Re%3A-enabling-tracing-info-whi
On 7/17/06, Mayuresh Nirhali <[EMAIL PROTECTED]> wrote:
>>Hello,
>>
>>I am trying to get tracing info for a test run in standalone
>>manner. The test runs fine, but I do not see the traceFile being
>>created.
I tried following but didn't get the trace file.
java -cp $CLASSPATH -Djvmflags=derby.d
Knut Anders Hatlen wrote:
Mayuresh Nirhali <[EMAIL PROTECTED]> writes:
Hello,
I am trying to get tracing info for a test run in standalone
manner. The test runs fine, but I do not see the traceFile being
created.
The command I use is as below,
java -cp $CLASSPATH -Dframework=DerbyNetCli
On 7/14/06, Knut Anders Hatlen <[EMAIL PROTECTED]> wrote:
Mayuresh Nirhali <[EMAIL PROTECTED]> writes:
> Hello,
>
> I am trying to get tracing info for a test run in standalone
> manner. The test runs fine, but I do not see the traceFile being
> created.
>
> The command I use is as below,
>
>
>
Mayuresh Nirhali <[EMAIL PROTECTED]> writes:
> Hello,
>
> I am trying to get tracing info for a test run in standalone
> manner. The test runs fine, but I do not see the traceFile being
> created.
>
> The command I use is as below,
>
>
> java -cp $CLASSPATH -Dframework=DerbyNetClient
> -DtestSpeci
Hello,
I am trying to get tracing info for a test run in standalone manner. The
test runs fine, but I do not see the traceFile being created.
The command I use is as below,
java -cp $CLASSPATH -Dframework=DerbyNetClient
-DtestSpecialProps=derby.infolog.append=true^derby.drda.traceFile=./tra
Myrna van Lunteren wrote:
On 7/10/06, Myrna van Lunteren <[EMAIL PROTECTED]> wrote:
Hi Gokul,
The test harness spawns off further java processes which may not
inherit the classpath if you use -cp. Please see what you get when you
add the classes dir, junit.jar and jakarta jar to an environment
Gokul Soundararajan wrote:
Hi Kristian,
Sorry for the late reply. I noticed that my code had some problems that wouldn't
allow me to run unit tests. Hopefully, all bugs are fixed now.
You were correct. JUnit was the problem and now the compile time errors are
gone. I think I may be running the
On 7/10/06, Myrna van Lunteren <[EMAIL PROTECTED]> wrote:
Hi Gokul,
The test harness spawns off further java processes which may not
inherit the classpath if you use -cp. Please see what you get when you
add the classes dir, junit.jar and jakarta jar to an environment
variable, then run the test
On 7/10/06, Gokul Soundararajan <[EMAIL PROTECTED]> wrote:
Hi Kristian,
Sorry for the late reply. I noticed that my code had some problems that wouldn't
allow me to run unit tests. Hopefully, all bugs are fixed now.
You were correct. JUnit was the problem and now the compile time errors are
gon
Hi Kristian,
Sorry for the late reply. I noticed that my code had some problems that wouldn't
allow me to run unit tests. Hopefully, all bugs are fixed now.
You were correct. JUnit was the problem and now the compile time errors are
gone. I think I may be running the test incorrectly. I have post
Gokul Soundararajan wrote:
Øystein Grøvlen <[EMAIL PROTECTED]> writes:
Gokul Soundararajan wrote:
1. 1st set related to BaseJDBCTestCase with method assertTrue()
2. 2nd set related to BaseJDBCTestCase.java/ScrollResultSetTest.java with
methods assertEquals(), assertTrue(), and assertF
Øystein Grøvlen <[EMAIL PROTECTED]> writes:
>
> Gokul Soundararajan wrote:
>
> > 1. 1st set related to BaseJDBCTestCase with method assertTrue()
> > 2. 2nd set related to BaseJDBCTestCase.java/ScrollResultSetTest.java with
> > methods assertEquals(), assertTrue(), and assertFalse()
> >
> > Thes
Gokul Soundararajan wrote:
1. 1st set related to BaseJDBCTestCase with method assertTrue()
2. 2nd set related to BaseJDBCTestCase.java/ScrollResultSetTest.java with
methods assertEquals(), assertTrue(), and assertFalse()
These errors seem related. Also, I get the same errors if I build from
${d
Hi Andrew,
Thanks for your help.
> The testing readme is in java/testing/README.htm.
I'm using this document as a guide.
> If you post the errors you are receiving at compile time and run time,
> I can help you track the problem down further.
I'm running ant inside java/testing/. I get 2 sets
On 7/1/06, Gokul Soundararajan <[EMAIL PROTECTED]> wrote:
In addition, when I make the derbyTesting package, I get several errors when
compiling JDBC related files.
Can someone point me to documentation on how to get the tests running? I don't
need to run all of them. Just testing the cache ser
Hi all,
I'm working on improving the Cache Manager. I have a working trunk copy. I can
run the ij tool and create/access databases. I want to run some tests to verify
my new implementation. I saw that there were some unit tests for the cache
service but I can't seem to get it running properly. The
Sounds great indeed - not sure the default should be to run tests with
a Security Manager installed but at least having the option to do it
would be neat for sure...Yes, running with or without a security
manager installed looks the same but internally am thinking that there
are behavioral differe
st harness. This then
means that running tests under the security manager really only makes
sense (or is a more stringent test) when running using jars (as opposed
to the classes directory).
I'm starting out by getting the embedded tests to run under the security
manager by just passing pr
, say, the embedded engine is not
incorrectly using a permission granted to the test harness. This then
means that running tests under the security manager really only makes
sense (or is a more stringent test) when running using jars (as opposed
to the classes directory).
I'm starting out by getti
Myrna van Lunteren wrote:
> Well, I have a j9_foundation.java, and only needed 1 tiny change to
> RunTest but when I tried to test, I found that ij still needs
> java.sql.Driver. So I can't actually test this until I/you/someone
> modifies ij...
>
> So, here is j9_foundation for now, please let m
Well, I have a j9_foundation.java, and only needed 1 tiny change to
RunTest but when I tried to test, I found that ij still needs
java.sql.Driver. So I can't actually test this until I/you/someone
modifies ij...
So, here is j9_foundation for now, please let me know if it doesn't work...
Myrna
Myrna van Lunteren wrote:
Note that with foundation, with wsdd5.6 there is no support for
java.sql.* (you'll get an incompatible library error if you try) and
with wctme5.7 foundation you are supposed to use jdbc.jar (again,
database_enabler.jar will give incompatible library with
Myrna van Lunteren wrote:
> After a night's sleep, I realize you probably need to have a jvm class
> for j9_foundation for wctme5.7. We had such a jvm class in the harness
> dir with earlier cloudscape versions for wsdd5.0 or wsdd5.5, but with
> wsdd5.6 the combo jcl-java.sql was not supported, so
After a night's sleep, I realize you probably need to have a jvm class
for j9_foundation for wctme5.7. We had such a jvm class in the harness
dir with earlier cloudscape versions for wsdd5.0 or wsdd5.5, but with
wsdd5.6 the combo jcl-java.sql was not supported, so I didn't
contribute that class.
I
On 5/12/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
> Myrna van Lunteren wrote:
>
> > On 5/12/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
>
> >
> >>One more question, how does the test harness map from the j9 vm to the
> >>j9_13.java representation of the JVM?
>
> Any idea on t
Myrna van Lunteren wrote:
> On 5/12/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
>
>>One more question, how does the test harness map from the j9 vm to the
>>j9_13.java representation of the JVM?
Any idea on this question?
>>
>>Onto CDC/Foundation ...
>
> Note that with foundation, wi
On 5/12/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
> Myrna van Lunteren wrote:
>
> > Is it possible JAVA_HOME is pointing to another jvm?
> > It would be one situation where you'd get the error you mention.
>
> Yep that was the problem, unsetting JAVA_HOME in my script fixed the
> probl
Myrna van Lunteren wrote:
> Is it possible JAVA_HOME is pointing to another jvm?
> It would be one situation where you'd get the error you mention.
Yep that was the problem, unsetting JAVA_HOME in my script fixed the
problem.
> And then it is required to add the bootclasspath to the location of
Is it possible JAVA_HOME is pointing to another jvm?
It would be one situation where you'd get the error you mention.
And then it is required to add the bootclasspath to the location of
the java.sql classes (e.g. database_enabler.jar), which is an
additional package, or you'll get java.sql.SQLExce
The README file for the testing implies that the tests should run with
IBM's wsdd5.6 (aka j9). Are there any examples on how to do this?
I tried this, with my classpath just set to include the Derby stuff, but
I get a java.lang.Object not found.
c:/wsdd5.6/ive/bin/j9 -jcl:Max
org.apache.derbyTes
1 - 100 of 103 matches
Mail list logo
