[
https://issues.apache.org/jira/browse/DELTASPIKE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14537133#comment-14537133
]
Mark Struberg commented on DELTASPIKE-897:
------------------------------------------
All our extensions DO have stable names. So this is not an valid argument from
my pov.
It also makes the syntax more easy imo. The current roll your own weird api
impl stuff is by far not as intuitive. I needed it once and it took me quite a
bit to get it right. It's surely not something one could do by just simply read
our docs and then impl a single class.
> 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)
