Additional Benefits:
Not only would adding this test case increase our JDBC coverage in the Samples integration testsuite, but it would also allow us to functionally test extraclasspath settings actually work.
Proposed Design:
hsqldb datasource will be configured as default into the samples pom.xml per the following:
<cargo.datasource.datasource>
cargo.datasource.url=jdbc:hsqldb:mem:jpa|
cargo.datasource.driver=org.hsqldb.jdbcDriver|
cargo.datasource.username=sa|
cargo.datasource.password=|
cargo.datasource.type=javax.sql.DataSource|
cargo.datasource.jndi=jdbc/CargoTest
</cargo.datasource.datasource>
A simple war will look up the test datasource via comp:env. The TestCase will validate success based on the response of this page.
- All containers that support datasource creation must add a deployment descriptor to the war to bind comp:env to the container-specific JNDI name for jdbc/CargoTest.
The design of this includes the following pieces:
HasDataSourceSupportValidator -> checks to see if Container Capability includes DatasourcePropertySet.DATASOURCE
AbstractDataSourceCapabilityContainerTestCase -> configures an in-memory hsqldb datasource and either checks for success
ExistingDataSourceCapabilityContainerTestCase -> tests on an existing local container, if support is there
StandaloneDataSourceCapabilityContainerTestCase -> tests on an standalone local container, if support is there
samples pom.xml -> addition of configuration to copy hsqldb jar to a known place so that it can be added to the classpath of the container.
Rationale for hsqldb:
hsqldb is a commonly used database and can be configured as in-memory. For unit test purposes, an in-memory database requires the least effort to configure. As the database itself is self-contained in a single jar which is accessible via public maven repositories, it has minimal risk of breaking in anyone's environment.
Rationale for web app:
-> JNDI naming and scope is not standardized across containers. Ex. JBoss defaults to java: context, whereas WebLogic has no prefix.
- using comp:env scope requires deployment descriptors per container, which works around this issue at the cost of violating the open-close principle of the test case.
- comp:env scope is only accessible to JavaEE components, of which the war is easiest to create and test.
Checking Logs:
-> checking for log messages would work, except that the server logfile locations are not standardized per container and it is possible that some may not output evidence of datasource creation. This additional work has a larger scope then this issue.
Test
Closed
Major
Additional Benefits:
Not only would adding this test case increase our JDBC coverage in the Samples integration testsuite, but it would also allow us to functionally test extraclasspath settings actually work.
Proposed Design:
hsqldb datasource will be configured as default into the samples pom.xml per the following:
<cargo.datasource.datasource>
cargo.datasource.url=jdbc:hsqldb:mem:jpa|
cargo.datasource.driver=org.hsqldb.jdbcDriver|
cargo.datasource.username=sa|
cargo.datasource.password=|
cargo.datasource.type=javax.sql.DataSource|
cargo.datasource.jndi=jdbc/CargoTest
</cargo.datasource.datasource>
A simple war will look up the test datasource via comp:env. The TestCase will validate success based on the response of this page.
The design of this includes the following pieces:
HasDataSourceSupportValidator -> checks to see if Container Capability includes DatasourcePropertySet.DATASOURCE
AbstractDataSourceCapabilityContainerTestCase -> configures an in-memory hsqldb datasource and either checks for success
ExistingDataSourceCapabilityContainerTestCase -> tests on an existing local container, if support is there
StandaloneDataSourceCapabilityContainerTestCase -> tests on an standalone local container, if support is there
samples pom.xml -> addition of configuration to copy hsqldb jar to a known place so that it can be added to the classpath of the container.
Rationale for hsqldb:
hsqldb is a commonly used database and can be configured as in-memory. For unit test purposes, an in-memory database requires the least effort to configure. As the database itself is self-contained in a single jar which is accessible via public maven repositories, it has minimal risk of breaking in anyone's environment.
Rationale for web app:
-> JNDI naming and scope is not standardized across containers. Ex. JBoss defaults to java: context, whereas WebLogic has no prefix.
Checking Logs:
-> checking for log messages would work, except that the server logfile locations are not standardized per container and it is possible that some may not output evidence of datasource creation. This additional work has a larger scope then this issue.