[ 
https://issues.apache.org/jira/browse/JCS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188758#comment-13188758
 ] 

Diego Rivera edited comment on JCS-87 at 1/18/12 10:30 PM:
-----------------------------------------------------------

Forgot to add that most of the failed tests (above) don't appear to have 
anything to do with the (RMI?) server not being started.  Furthermore, for 
newer mechanisms something like an embedded tomcat (Jetty?) could be used when 
that's needed for integration tests, perhaps there are plugins to start the RMI 
server for the same purpose, etc?
                
      was (Author: diego.rivera...@gmail.com):
    Forgot to add that most of the failed tests (above) don't appear to have 
anything to do with the (RMI?) server not being started.  Furthermore, for 
newer mechanisms something like an embedded tomcat (Jetty?) could be used when 
that's needed for integration tests, using commons-daemon 
                  
> Migrate to build with Maven 3.0
> -------------------------------
>
>                 Key: JCS-87
>                 URL: https://issues.apache.org/jira/browse/JCS-87
>             Project: Commons JCS
>          Issue Type: Improvement
>    Affects Versions: jcs-1.3
>            Reporter: Diego Rivera
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Evidently, the documentation clearly states that Maven 1.x is the only 
> supported mechanism to build JCS.  However, this is very dated and it 
> wouldn't be a bad idea to update the build process to more modern/current 
> standards.
> I've tried to do this, and have run into a few snags wrt tests - I get many 
> unit tests failures in what I expect should have been trivial tests:
> Failed tests:   
> testIndexedDiskCache4(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheSameRegionConcurrentUnitTest$4):
>  expected:<indexedRegion4 data 2200> but was:<null>
>   
> testIndexedDiskCache5(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheSameRegionConcurrentUnitTest$5):
>  expected:<indexedRegion4 data 0> but was:<null>
>   
> testIndexedDiskCache1(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheNoMemoryUnitTest$1):
>  expected:<indexedRegion1 data 0> but was:<null>
>   
> testIndexedDiskCache3(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheNoMemoryUnitTest$3):
>  expected:<indexedRegion3 data 0> but was:<null>
>   
> testIndexedDiskCache2(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheNoMemoryUnitTest$2):
>  expected:<indexedRegion2 data 0> but was:<null>
>   
> testBlockDiskCache1(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$1):
>  Wrong value for key [0:key] expected:<blockRegion4 data 0-blockRegion4> but 
> was:<null>
>   
> testBlockDiskCache2(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$2):
>  Wrong value for key [1000:key] expected:<blockRegion4 data 
> 1000-blockRegion4> but was:<null>
>   
> testBlockDiskCache3(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$3):
>  Wrong value for key [2000:key] expected:<blockRegion4 data 
> 2000-blockRegion4> but was:<null>
>   
> testBlockDiskCache4(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$4):
>  Wrong value for key [2200:key] expected:<blockRegion4 data 
> 2200-blockRegion4> but was:<null>
>   
> testExpireInBackground(org.apache.jcs.auxiliary.disk.jdbc.JDBCDiskCacheShrinkUnitTest):
>  Removed key should be null: 0:key
>   
> testSpoolEvent(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest):
>  The number of ELEMENT_EVENT_SPOOLED_DISK_AVAILABLE events [0] does not equal 
> the number expected [20000]
>   
> testSpoolNoDiskEvent(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest):
>  The number of ELEMENT_EVENT_SPOOLED_DISK_NOT_AVAILABLE events  [19002] does 
> not equal the number expected.
>   
> testSpoolNotAllowedEvent(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest):
>  The number of ELEMENT_EVENT_SPOOLED_NOT_ALLOWED events [0] does not equal 
> the number expected.
>   
> testSpoolNotAllowedEventOnItem(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest):
>  The number of ELEMENT_EVENT_SPOOLED_NOT_ALLOWED events [0] does not equal 
> the number expected.
>   
> testUpdateConfig(org.apache.jcs.engine.control.CompositeCacheDiskUsageUnitTest):
>  expected:<1> but was:<0>
>   testSystemPropertyUsage(org.apache.jcs.engine.SystemPropertyUsageUnitTest): 
> System property value is not reflected expected:<1000> but was:<6789>
>   testLoadFromCCF(org.apache.jcs.engine.memory.mru.MRUMemoryCacheUnitTest): 
> Cache name should have MRU in it.
>   
> testGetStatsThroughHub(org.apache.jcs.engine.memory.mru.MRUMemoryCacheUnitTest):
>  Should have 200 puts
>   
> testDefaultConfigUndefinedPool(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest):
>  expected:<150> but was:<151>
>   
> testNonExistentConfigFile(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest):
>  expected:<150> but was:<151>
>   
> testWaitPolicyConfig(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest):
>  Max is wrong expected:<150> but was:<11>
>   testNoBoundary(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest): 
> Should have a linked queue and not a bounded buffer.
>   
> testSystemPropertyInValueDelimeter(org.apache.jcs.access.SystemPropetyUnitTest):
>  We should have used the system property for the memory size expected:<1234> 
> but was:<6789>
> Tests in error: 
>   
> test(org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPFilterRemoveHashCodeUnitTest):
>  Socket is null, cannot connect to localhost:1110
>   
> testPutLocalPutRemoteGetBusyVerifyRemoved(org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPIssueRemoveOnPutUnitTest):
>  Socket is null, cannot connect to localhost:1110
>   
> testStandardPut(org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPIssueRemoveOnPutUnitTest):
>  Socket is null, cannot connect to localhost:1110
> Clearly something needs to be started to listen on that port (the RMI server, 
> maybe?).  However, the build documentation makes no mention of this anywhere. 
>  Migrating to a newer build mechanism may not fix this (and other) issues, 
> but it would help revise the build process and perhaps find more elegant and 
> future-proof mechanisms to meet these testing requirements.
> If you'd like help implementing this feature, I might be able to provide time 
> and effort towards this goal if someone helps me understand the full build 
> process top-to-bottom.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to