Tapestry 5
  1. Tapestry 5
  2. TAP5-966

TapestryFilter should be able add additional modules to the Registry to accomidate different testing (or other) execution configurations

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 5.2.0
    • Fix Version/s: 5.2.0
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      Frequently when integration testing an application, it is desirable to re-configure some parts of it (i.e., special symbol defaults, new service overrides, special service configurations), which currently is ad-hoc or otherwise awkward.

      How about if there was a special JVM system property: tapestry.execution-mode. This would be a comma-seperated list of mode names. For each one, the T5 filter would check for a <init-parameter> named "tapestry.foo-modules" (where "foo" is a mode name) and add those to the Registry. The default value for execution-mode would be "production" ... thus you could easily have certain module classes loaded for normal production and a different set loaded for integration testing.

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        1d 21h 22m 1 Howard M. Lewis Ship 02/Jan/10 20:20
        In Progress In Progress Closed Closed
        2d 22h 19m 1 Howard M. Lewis Ship 05/Jan/10 18:39
        Howard M. Lewis Ship made changes -
        Status In Progress [ 3 ] Closed [ 6 ]
        Fix Version/s 5.2.0 [ 12314122 ]
        Resolution Fixed [ 1 ]
        Howard M. Lewis Ship made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Howard M. Lewis Ship made changes -
        Field Original Value New Value
        Summary TapestryFilter should support a test mode (from a JVM system proprerty) and an init parameter to specify additional module classes when in test mode TapestryFilter should be able add additional modules to the Registry to accomidate different testing (or other) execution configurations
        Assignee Howard M. Lewis Ship [ hlship ]
        Description Frequently when integration testing an application, it is desirable to re-configure some parts of it (i.e., special symbol defaults, new service overrides, special service configurations), which currently is ad-hoc or otherwise awkward.

        If the T5 filter included an init-param "tapestry.test-modules" as a comma-separated list of module classes to load (in addition to the default) that would be great.

        Possibly this could be generalized to a "run-mode" that could be "test" or "integration" (or any arbitrary string) and Tapestry would include "tapestry.xyz-modules" if it exists as an init param. The default would be "production" which would allow for some large scale swapping out of production modules vs. test modules.
        Frequently when integration testing an application, it is desirable to re-configure some parts of it (i.e., special symbol defaults, new service overrides, special service configurations), which currently is ad-hoc or otherwise awkward.

        How about if there was a special JVM system property: tapestry.execution-mode. This would be a comma-seperated list of mode names. For each one, the T5 filter would check for a <init-parameter> named "tapestry.foo-modules" (where "foo" is a mode name) and add those to the Registry. The default value for execution-mode would be "production" ... thus you could easily have certain module classes loaded for normal production and a different set loaded for integration testing.
        Howard M. Lewis Ship created issue -

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Howard M. Lewis Ship
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development