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 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.
No, I meant adding something like
if (Float.parseFloat(System.getProperty("java.specification.version")) <
1.6f) {
if(null == System.getProperty("org.xml.sax.driver")) {
System.setProperty("org.xml.sax.driver","org.apache.xerces.parsers.SAXParser");
}
}
to the ctor of both JOCL tests.
[snip]
> 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 ;)
:D
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
