[
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.
