[ https://issues.apache.org/jira/browse/DELTASPIKE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176347#comment-13176347 ]
Gerhard Petracek commented on DELTASPIKE-36: -------------------------------------------- we could think about using the config approach used by owb. instead of using Deactivatable and @InvocationOrder for 1-n implementations of ConfiguredValueResolver, there would be only one implementation which has to be configured via a properties file and with configuration.ordinal a custom config can overrule the default impl. advantage: + there is only one active impl of the service + no need to aggregate the result of multiple service implementations disadvantage: - the default impl. can't be re-used easily if a custom impl. is only responsible for some but not all configured values or a custom impl. allows to overrule the default config-source if there are configured values in a custom config-source - configuration.ordinal isn't type-safe - configuration.ordinal is an additional mechanism (@InvocationOrder is also used for ordering other artifacts like phase-listeners,...) > review and discuss ConfiguredValueResolver > ------------------------------------------ > > Key: DELTASPIKE-36 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-36 > Project: DeltaSpike > Issue Type: Task > Components: Core > Reporter: Gerhard Petracek > Assignee: Gerhard Petracek > > for several features we need a pluggable config-service which has to be > independent of cdi because it's needed e.g. during the bootstrapping process > of a cdi container. > an implementation is aware of a config source like property-files or xml > files or jndi values and has to return 1-n configured values for a given key. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira