Cargo
  1. Cargo
  2. CARGO-640

Create Samples TestCase for JDBC

    Details

    • Type: Test Test
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.9
    • Fix Version/s: 1.0
    • Component/s: Core
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      Currently, the Samples module includes many testcases for validating containers' ability to deploy files. Since we support JDBC DataSource creation, we should also implement a test to validate that the support works.

        Activity

        Hide
        Adrian Cole added a comment -

        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.

        Show
        Adrian Cole added a comment - 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.
        Hide
        Adrian Cole added a comment -

        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.

        Show
        Adrian Cole added a comment - 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.
        Hide
        Alexander added a comment -

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

        Show
        Alexander added a comment - If you'd like the ability to handle multiple datasources you can take a look at CARGO-608 .
        Hide
        Adrian Cole added a comment -

        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

        Show
        Adrian Cole added a comment - 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

          People

          • Assignee:
            Adrian Cole
            Reporter:
            Adrian Cole
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 2 days Original Estimate - 2 days
              2d
              Remaining:
              Time Spent - 2 days Remaining Estimate - 1 day
              1d
              Logged:
              Time Spent - 2 days Remaining Estimate - 1 day
              2d