Uploaded image for project: 'DeltaSpike'
  1. DeltaSpike
  2. DELTASPIKE-785

Make CdiTestRunner pick up container configuration from properties file

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.1.0
    • 1.2.0
    • TestControl
    • None

    Description

      For doing 'real' EE tests we need to be able to configure those containers when it boots up. CdiCtrl already has a boot(Properties) which we can use very easily.

      That way openejb-embedded, glassfish-embedded and wildfly-embedded can e.g. register DataSources for the unit tests.

      Attachments

        Activity

          struberg Mark Struberg added a comment -

          I've implemented a 2-staged lookup.

          A first lookup will check for a "cdiTestRunnerConfig" property via ConfigResolver (default of this value is "cdiTestRunnerConfig" again).

          This value will be used to pick up property files (via PropertyLoader, thus you can use many of them and use ordinals to tweak values) which will get feeded into CdiContainer#boot(bootProperties).

          struberg Mark Struberg added a comment - I've implemented a 2-staged lookup. A first lookup will check for a "cdiTestRunnerConfig" property via ConfigResolver (default of this value is "cdiTestRunnerConfig" again). This value will be used to pick up property files (via PropertyLoader, thus you can use many of them and use ordinals to tweak values) which will get feeded into CdiContainer#boot(bootProperties).

          +1 for the basic idea, however, there were some issues (esp. the location and name of the default config).
          however, it's fixed now and i've added a basic test for it.

          gpetracek Gerhard Petracek added a comment - +1 for the basic idea, however, there were some issues (esp. the location and name of the default config). however, it's fixed now and i've added a basic test for it.
          karlkilden Karl Kildén added a comment -

          Awesome! Been waiting for this one. I will try it next week

          karlkilden Karl Kildén added a comment - Awesome! Been waiting for this one. I will try it next week

          i added a 2nd test as well as a short documentation about it.

          gpetracek Gerhard Petracek added a comment - i added a 2nd test as well as a short documentation about it.
          gpetracek Gerhard Petracek added a comment - - edited

          @karl:
          imo it's the responsibility of the container itself to provide different approaches to find such a config (via param. should be just one of it) and it's a feature which is just portable in theory since only one container (we support out-of-the-box) supports that at all.
          however, i'm ok with that suggestion since it doesn't pollute the api itself.

          @all:
          everybody is welcome to suggest better names, however, we need "deltaspike." as prefix for the project-stage based config (since it can be provided by any config-source and that's our prefix we use already) and the default config for the test-container is META-INF/apache-deltaspike_test-container.properties since we have META-INF/apache-deltaspike.properties as name already and it should be clean for users that it isn't a config for deltaspike itself, instead it's a config picked up by deltaspike and forwarded to the test-container.
          for sure we could reuse META-INF/apache-deltaspike.properties, but imo it's strange to see other deltaspike-config-values in the test-container (e.g. during debugging)

          gpetracek Gerhard Petracek added a comment - - edited @karl: imo it's the responsibility of the container itself to provide different approaches to find such a config (via param. should be just one of it) and it's a feature which is just portable in theory since only one container (we support out-of-the-box) supports that at all. however, i'm ok with that suggestion since it doesn't pollute the api itself. @all: everybody is welcome to suggest better names, however, we need "deltaspike." as prefix for the project-stage based config (since it can be provided by any config-source and that's our prefix we use already) and the default config for the test-container is META-INF/apache-deltaspike_test-container.properties since we have META-INF/apache-deltaspike.properties as name already and it should be clean for users that it isn't a config for deltaspike itself, instead it's a config picked up by deltaspike and forwarded to the test-container. for sure we could reuse META-INF/apache-deltaspike.properties, but imo it's strange to see other deltaspike-config-values in the test-container (e.g. during debugging)
          struberg Mark Struberg added a comment -

          gpetracek The main reason why this is a distinct config file is that this effective file is NOT loaded as ConfigSource. It is not read via ConfigResolver but via PropertyLoader. You know, the thing which just reads all the resources with this name from the ClassPath and then sort them according their deltaspike_ordinal.

          struberg Mark Struberg added a comment - gpetracek The main reason why this is a distinct config file is that this effective file is NOT loaded as ConfigSource. It is not read via ConfigResolver but via PropertyLoader. You know, the thing which just reads all the resources with this name from the ClassPath and then sort them according their deltaspike_ordinal.

          @mark: i know & +1 (i just wrote the comment for the records -> thx for providing an additional reason.)

          @karl:
          nonetheless it isn't portable across modules provided by deltaspike itself. portability doesn't only mean that there is an api which can be called. the important part is that the resulting behavior is as expected. you can use it but only one test-container we support out-of-the-box will process it. if you implement adapters for containers we don't support out-of-the-box, you can load any config-file in the adapter itself.
          however, we don't have to restart the discussion again. i just mentioned that the basic topic is still the same, but it's documented and users have to take it as it is (which means that a lot of them have to ignore it). imo that compromise (= no api change) is ok for everybody (at least to some degree).

          gpetracek Gerhard Petracek added a comment - @mark: i know & +1 (i just wrote the comment for the records -> thx for providing an additional reason.) @karl: nonetheless it isn't portable across modules provided by deltaspike itself. portability doesn't only mean that there is an api which can be called. the important part is that the resulting behavior is as expected. you can use it but only one test-container we support out-of-the-box will process it. if you implement adapters for containers we don't support out-of-the-box, you can load any config-file in the adapter itself. however, we don't have to restart the discussion again. i just mentioned that the basic topic is still the same, but it's documented and users have to take it as it is (which means that a lot of them have to ignore it). imo that compromise (= no api change) is ok for everybody (at least to some degree).

          People

            struberg Mark Struberg
            struberg Mark Struberg
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: