Create Samples TestCase for JDBC

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.

Seems Derby may a better pick as an embedded DB as it will allow us to test XADatasource. hsqldb 1.8 does not support XA.

If you'd like the ability to handle multiple datasources you can take a look at CARGO-608.

added two new samples web modules:
datasource-war and two-datasources.war

referenced these in the resources/testdata/pom.xml and core/samples/pom.xml

Created DataSourceOnStandaloneConfigurationTest and a base class AbstractDataSourceWarCapabilityContainerTestCase