You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org> on 2009/12/31 23:58:29 UTC

[jira] Created: (TAP5-966) 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 support a test mode (from a JVM system proprerty) and an init parameter to specify additional module classes when in test mode
----------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: TAP5-966
                 URL: https://issues.apache.org/jira/browse/TAP5-966
             Project: Tapestry 5
          Issue Type: New Feature
          Components: tapestry-core
    Affects Versions: 5.2.0
            Reporter: Howard M. Lewis Ship
            Priority: Minor


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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TAP5-966) TapestryFilter should be able add additional modules to the Registry to accomidate different testing (or other) execution configurations

Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship updated TAP5-966:
--------------------------------------

    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.

  was:
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.

       Assignee: Howard M. Lewis Ship
        Summary: TapestryFilter should be able add additional modules to the Registry to accomidate different testing (or other) execution configurations  (was: 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
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-966
>                 URL: https://issues.apache.org/jira/browse/TAP5-966
>             Project: Tapestry 5
>          Issue Type: New Feature
>          Components: tapestry-core
>    Affects Versions: 5.2.0
>            Reporter: Howard M. Lewis Ship
>            Assignee: Howard M. Lewis Ship
>            Priority: Minor
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TAP5-966) TapestryFilter should be able add additional modules to the Registry to accomidate different testing (or other) execution configurations

Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship updated TAP5-966:
--------------------------------------

    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.

  was:
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.

       Assignee: Howard M. Lewis Ship
        Summary: TapestryFilter should be able add additional modules to the Registry to accomidate different testing (or other) execution configurations  (was: 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
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-966
>                 URL: https://issues.apache.org/jira/browse/TAP5-966
>             Project: Tapestry 5
>          Issue Type: New Feature
>          Components: tapestry-core
>    Affects Versions: 5.2.0
>            Reporter: Howard M. Lewis Ship
>            Assignee: Howard M. Lewis Ship
>            Priority: Minor
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (TAP5-966) TapestryFilter should be able add additional modules to the Registry to accomidate different testing (or other) execution configurations

Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship closed TAP5-966.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 5.2.0

> TapestryFilter should be able add additional modules to the Registry to accomidate different testing (or other) execution configurations
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-966
>                 URL: https://issues.apache.org/jira/browse/TAP5-966
>             Project: Tapestry 5
>          Issue Type: New Feature
>          Components: tapestry-core
>    Affects Versions: 5.2.0
>            Reporter: Howard M. Lewis Ship
>            Assignee: Howard M. Lewis Ship
>            Priority: Minor
>             Fix For: 5.2.0
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (TAP5-966) TapestryFilter should be able add additional modules to the Registry to accomidate different testing (or other) execution configurations

Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship closed TAP5-966.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 5.2.0

> TapestryFilter should be able add additional modules to the Registry to accomidate different testing (or other) execution configurations
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-966
>                 URL: https://issues.apache.org/jira/browse/TAP5-966
>             Project: Tapestry 5
>          Issue Type: New Feature
>          Components: tapestry-core
>    Affects Versions: 5.2.0
>            Reporter: Howard M. Lewis Ship
>            Assignee: Howard M. Lewis Ship
>            Priority: Minor
>             Fix For: 5.2.0
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.