[
https://issues.apache.org/jira/browse/DELTASPIKE-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229169#comment-17229169
]
Andrew Marinchuk commented on DELTASPIKE-1417:
----------------------------------------------
Hi Mark! Of course, onExpression works great (we've implemented own expresion
interpreter to check the current projectStage).
But onExpression is only applicable for annotation, not for application config.
For example, we have a single database server for all testing projectStages.
And now we have to write something like:
{code:title=app.properties}db.server.Development=localhost
db.server.UnitTest=test-server.local
db.server.SystemTest=test-server.local
db.server.IntegrationTest=test-server.local
db.server.Production=prod-server.local{code}
or something like:
{code:title=app.properties}db.server.Development=localhost
db.server.UnitTest=test-server.local
db.server.SystemTest=${db.server.UnitTest}
db.server.IntegrationTest=${db.server.UnitTest}
db.server.Production=prod-server.local{code}
Actually, we use own project stages set and several other setting parameters
with such duplication.
Of course, we can switch from getProjectStageAwarePropertyValue to
getPropertyAwarePropertyValue, but it will require to change many places of
code. In addition, parameterization by one parameter gives us only one
parameterization dimension, however you can introduce interface markers for
projectStage as many times as you want. Of course, it could lead to the
ambiguousness of config, but this situations could be detected if all the
interface markers will be marked itself with same marker interface (so, it's
possible to enum all them).
> ProjectStage inheritance
> ------------------------
>
> Key: DELTASPIKE-1417
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1417
> Project: DeltaSpike
> Issue Type: Wish
> Security Level: public(Regular issues)
> Components: Core
> Reporter: Andrew Marinchuk
> Priority: Major
>
> Currently ProjectStage is single typesafe param which allow to divide single
> configuration (including bean visibility) to several configurations. But each
> configuration should be described separately. For each configuration property
> we have to choose from two options:
> * use the same value for all project stages
> * put the separate configuration line for each project stage with non-default
> value (the value could be specified single time thanks to ability to refer
> another line, but)
> Moreover, when there is a need to use projectstage in the {{@Exclude}}
> annotation, adding the new projectstage leads to potential modifications of
> all classes annotated with {{@Exclude}}.
> Default project stages are bandled with marker interface
> org.apache.deltaspike.core.api.projectstage.TestStage attached to the testing
> projectstages, but it's not used anywhere. The idea is to use marker
> interfaces to define additional "virtual" projectstages. Such interfaces have
> not used as org.apache.deltaspike.ProjectStage value, but it could be used in
> configuration or with {{@Exclude}} annotations, i.e.:
> {code}#dev stage server
> db.server.hostname.Development=dev-host.dom
> #server for all test stages
> db.server.hostname.TestStage=test-host.dom
> #server for integration tests - projectstage name has priority, so it
> overrides value for TestStage
> db.server.hostname.IntegrationTest=itg-test-host.dom{code}
> This feature is very usable for custom projectstages because enough
> additional interfaces could be provided.
> The only problem is conflicting settings. For example, if we have two marker
> interfaces attached to the same projectstage, but some config property has
> two different marker-aware values and no projectstage-aware value provided.
> This situation is definitely a configuration bug, so the only valid option is
> to throw exception on such situation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
