[jira] [Commented] (DELTASPIKE-1417) ProjectStage inheritance

["Andrew Marinchuk (Jira)" <ji...@apache.org>]

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