You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "Gerhard Petracek (JIRA)" <ji...@apache.org> on 2015/06/12 20:40:05 UTC

[jira] [Updated] (DELTASPIKE-897) discuss configuration of a ClassDeactivator

     [ https://issues.apache.org/jira/browse/DELTASPIKE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gerhard Petracek updated DELTASPIKE-897:
----------------------------------------
    Fix Version/s:     (was: 1.4.1)
                   1.4.2

> discuss configuration of a ClassDeactivator
> -------------------------------------------
>
>                 Key: DELTASPIKE-897
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-897
>             Project: DeltaSpike
>          Issue Type: Task
>          Components: Core
>            Reporter: Gerhard Petracek
>            Assignee: Gerhard Petracek
>             Fix For: 1.4.2
>
>
> currently it's needed to configure a custom ClassDeactivator via apache-deltaspike.properties, but not via META-INF/services/org.apache.deltaspike.core.spi.activation.ClassDeactivator
> this limitation was required, because it isn't possible to deactivate/overrule a ClassDeactivator configured via the std. spi-config, but via config-sources and ordinals it's possible to overrule it.
> that's basically fine, but not that intuitive esp. because it's a spi for a low-level functionality -> users expect a std. spi-config. therefore we should combine both or provide a corresponding hint/warning.
> #1
> usually there is just one configured ClassDeactivator and therefore we can support both config formats easily. once there is at least one ClassDeactivator configured in apache-deltaspike.properties, we can ignore all implementations of ClassDeactivator configured via the std. spi-config. that allows to deactivate/overrule such a configuration. currently we just support one ClassDeactivator at runtime. that's limited by the config-format itself. since a std. spi-config allows multiple config-entries, we would need to use an internal instance which aggregates instances of the configured classes.
> #2
> we just check if there is an active spi-config for 1-n implementations of ClassDeactivator and in such cases we log a warning that they are ignored and how to configure a ClassDeactivator correctly (and that only one active implementation is supported).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)