jakarta-jcs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Eade <se...@backstagetech.com.au>
Subject Re: Working towards a formal jcs release...
Date Fri, 06 Apr 2007 15:18:08 GMT
Okay - not sure what was going on before.  I deleted the jars directory 
created by copyjars and ran a maven clean and now they compile fine - 
there must have been some cruft in my target directly somewhere.

There are still a number of failures, but it looks like there is some 
cleanup that is not happening between tests that is causing an earlier 
failure to retail a lock that is then causing later failures.  I get 
something like this:

Testcase: 
testBasicOptimization(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheOptimizationUnitTest):
   
FAILED
The post optimization size should be smaller.
junit.framework.AssertionFailedError: The post optimization size should 
be smaller.
    at 
org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheOptimizationUnitTest.testBasicOptimization(IndexedDiskCacheOptimizationUnitTest.java:71)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: 
testBasicPutRemove(org.apache.jcs.auxiliary.disk.jdbc.hsql.HSQLDiskCacheUnitTest):    
FAILED
key = [0:key] value = [null] expected:<testCache data 0> but was:<null>
junit.framework.ComparisonFailure: key = [0:key] value = [null] 
expected:<testCache data 0> but was:<null>
    at 
org.apache.jcs.auxiliary.disk.jdbc.hsql.HSQLDiskCacheUnitTest.testBasicPutRemove(HSQLDiskCacheUnitTest.java:79)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: 
testRemoveAllProhibition(org.apache.jcs.auxiliary.disk.jdbc.hsql.HSQLDiskCacheUnitTest): 
  
FAILED
key = [0:key] value = [null] expected:<noRemoveAll data 0> but was:<null>
junit.framework.ComparisonFailure: key = [0:key] value = [null] 
expected:<noRemoveAll data 0> but was:<null>
    at 
org.apache.jcs.auxiliary.disk.jdbc.hsql.HSQLDiskCacheUnitTest.testRemoveAllProhibition(HSQLDiskCacheUnitTest.java:170)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: 
testPartialKeyRemoval_Good(org.apache.jcs.auxiliary.disk.jdbc.JDBCDiskCacheRemovalUnitTest):
   
Caused an ERROR
The database is already in use by another process: 
org.hsqldb.persist.NIOLockFile@7e953145[file 
=S:\eclipse-workspace\jakarta-jcs\target\cache_hsql_db.lck, exists=true, 
locked=false, valid=false, fl =null]: java.lang.Exception: 
checkHeartbeat(): lock file 
[S:\eclipse-workspace\jakarta-jcs\target\cache_hsql_db.lck] is 
presumably locked by another process.
java.sql.SQLException: The database is already in use by another 
process: org.hsqldb.persist.NIOLockFile@7e953145[file 
=S:\eclipse-workspace\jakarta-jcs\target\cache_hsql_db.lck, exists=true, 
locked=false, valid=false, fl =null]: java.lang.Exception: 
checkHeartbeat(): lock file 
[S:\eclipse-workspace\jakarta-jcs\target\cache_hsql_db.lck] is 
presumably locked by another process.
    at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
    at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
    at org.hsqldb.jdbcDriver.getConnection(Unknown Source)

And then a few more failures the same as the last one above.

Scott

Smuts, Aaron wrote:
> I don't have a jars directory.  This is only needed to run the manual
> tester scripts.  I haven't run those in some time, and not in my current
> workspace.  What test exactly doesn't compile if you don't have the jars
> directory?  That would be very strange since the Eclipse can compile
> everything using the classpath generated from maven eclipse, which makes
> no reference to the jars directory.  
>
>   
>> -----Original Message-----
>> From: Scott Eade [mailto:seade@backstagetech.com.au]
>> Sent: Friday, April 06, 2007 10:30 AM
>> To: JCS Developers List
>> Subject: Re: Working towards a formal jcs release...
>>
>> Smuts, Aaron wrote:
>>     
>>> None of the tests fail for me and you definitely do not need to run
>>> copyjars to run the unit tests.  What jdk version are you testing
>>>       
> with?
>   
>> JAVA_HOME=C:\jdk1.5.0_09
>>
>> If I don't run copyjars some of the test classes fail to compile.  Try
>> deleting your jars directory and see what happens.
>>
>> Scott
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
>
>   



---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org


Mime
View raw message