[
https://issues.apache.org/jira/browse/DELTASPIKE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14537310#comment-14537310
]
Gerhard Petracek commented on DELTASPIKE-897:
---------------------------------------------
yes - for deactivating deactivatable ds-artifacts, you can be quite sure that
they won't change (frequently).
however, to reuse the concept e.g. for feature switches or something similar,
it isn't that nice (because it isn't type-safe).
maybe you used it before it was documented.
imo http://deltaspike.apache.org/documentation/core.html#Deactivatable is quite
clear and short and i can't see why someone would need more than 5min.
several ds-users used it already and they just needed that link.
you might had issues with deactivating classes of the impl.modules, in case you
used scope "runtime" for them.
in that case or any other more complex module-case, you can just fall back to
check the fully qualified name. that isn't type-safe for sure, however, with
this new syntax you have the same issue + you need to know the syntax itself
and not just the fully qualified name.
option #1 wouldn't help in case of the impl.module topic, but at least in case
of more complex module use-cases (because you would be able to provide a
ClassDeactivator per module).
> 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.1
>
>
> 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)
