[
https://issues.apache.org/jira/browse/DELTASPIKE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535496#comment-14535496
]
Gerhard Petracek commented on DELTASPIKE-897:
---------------------------------------------
(if it's really needed) #3 could be done in addition, however, imo it makes
only sense for parts which have a stable fully qualified name (over time),
because that syntax makes maintenance more complex (+ we add even more magical
config-syntax - which we avoided so far, because it's even worse than with
xml-configs).
the point with #1/#2 is: imo users expect a std. spi-config in this case. we
can address it by defining 1-2 rules which are usually easy enough and users
won't even notice that they are in place. however, it could get a bit more
complex if users try to mix the available options in large projects and
therefore the 2nd option would be to add an additional check (+ warnings for
wrong std. spi-config-entries) instead of the additional support for a std.
spi-config option.
> 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)
