commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [VOTE] Release DBCP 1.3/1.4
Date Wed, 23 Dec 2009 16:09:40 GMT
Phil Steitz wrote:

> 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 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.

No, I meant adding something like

    if (Float.parseFloat(System.getProperty("java.specification.version")) < 
1.6f) {
        if(null == System.getProperty("org.xml.sax.driver")) {

to the ctor of both JOCL tests.


> 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.

Yeah, those VMs can really create a headache if you need synchronized times 
or depend on time resolution.

>> I wish I'd not be always the one reporting the next problem ;-)
> Admit it, you love this stuff ;)


- Jörg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message