Jörg Schaible wrote: > Hi Phil, > > Phil Steitz wrote: > >> Jörg Schaible wrote: > > [snip] > >>> I've modified the trunk and 1.3-branch now. In the 1.3 branch both JOCL >>> tests set the SAX driver explicitly now and the used xerces artifact has >>> been harmonized between Ant and Maven build. Also the proper xml-apis is >>> used now. In trunk I dropped the XML dependencies and the explicit >>> setting in the JOCL test completely, since it runs OOTB with Java 6. I >>> also adjusted the 1.3 pom and build.properties.sample in trunk. However, >>> I wonder if we should drop this anyway, because you cannot build 1.3 from >>> trunk anyway (mvn -f pom-1.3.pom), because of the dropped source >>> filtering for the JDBC 3/4 stuff. Changes from trunk can wait for the >>> next release though. >> What I am trying to maintain here is a simple way to just cut a >> branch from trunk and then make some simple changes (see >> release-process.txt) to cut a 1.3.x release. > > OK. > >> I would *really* like >> to avoid having to individually back port changes to the 1.3 branch. >> So I need somehow to isolate the required changes to either >> filtering or 1.3-compat config files. I am inclined to just mark >> the TestJOCLed stuff for filtering. > > We could explicitly set the SAX driver in the two JOCL tests if running with > Java 5 or lower. That would keep a single source.
How do we detect the JVM version using maven? I would be OK with that, or just filtering out the test altogether. > >>> One last thing: I had one time a NPE that did not result in a failed test >>> (probably because it happened in a different thread): >>> ================ %< =============== >>> Running org.apache.commons.dbcp.datasources.TestSharedPoolDataSource >>> testMaxWait took 1102 ms >>> Exception in thread "Thread+33" java.lang.NullPointerException >>> at >>> > org.apache.commons.dbcp.datasources.TestSharedPoolDataSource$1.uncaughtException(TestSharedPoolDataSource.java:389) >>> Multithread test time = 645 ms >>> Multithread test time = 2326 ms >>> Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.089 >>> sec >> This is a timing error that occurs sporadically. The test should be >> fixed or eliminated. > > There seems another one failing sporadically at Continuum: > > ================== %< ================ > TestPerUserPoolDataSource > testMultipleThreads : > junit.framework.AssertionFailedError > junit.framework.AssertionFailedError > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.assertTrue(Assert.java:20) > at junit.framework.Assert.assertTrue(Assert.java:27) > at > org.apache.commons.dbcp.datasources.TestPerUserPoolDataSource.testMultipleThreads(TestPerUserPoolDataSource.java:377) > Another timing issue. The setup used in TestPerUserPoolDataSource and TestSharedPoolDataSource is, well, fragile. The 1.5.x versions of pool make it a little worse, since they provide both fairness and better concurrency. What is going on in the case above is the pool is - miraculously - able to successfully serve 2 * maxActive threads, all of which hold onto their connections for 2 * maxWait ms. The Continuum instance is running in a VM that does not have the greatest time resolution. That combined with thread start and scheduling variability (and great pool performance ;) can result in this test failing. > ================== %< ================ > >> Thanks again for your help on this. > > I wish I'd not be always the one reporting the next problem ;-) Admit it, you love this stuff ;) Thanks! Phil > > Cheers, > Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
