[
https://issues.apache.org/jira/browse/DELTASPIKE-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17222181#comment-17222181
]
Andrew Marinchuk commented on DELTASPIKE-1417:
----------------------------------------------
The initial reason for this wish is our need to make the extensible subset of
projectstages with a similar configurations and bean visibility. Our current
solution is custom script interpreter specified in {{interpretedBy}} option of
{{@Exclude}} which takes the fully qualified marker interface name from
{{onExpression}} and checks whether the projectstage implements provided
interface. But this solutions does not help to get rid of configuration
dublications
> 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)
