Introduction¶

Deactivatable¶

This mechanism is only used for artifacts like implementations of (javax.enterprise.inject.spi.Extension) which can't be deactivated with std. CDI mechanisms.

This interface is just a marker interface which is implemented by all pre-configured DeltaSpike artifacts which can be deactivated manually (e.g. to improve the performance if a part isn't needed, to provide a custom implementation if the default implementation isn't pluggable by default or to bypass an implementation which causes an issue (in this case please also contact us and we will fix it)).

To deactivate a class it's required to implement ClassDeactivator. Returning 'false' or 'true' allows to de-/activate the class in question. Retuning null means that the current class-deactivator doesn't have information about the class in question and can't provide a result. Since ClassDeactivator implementations are configured with the low-level config of DeltaSpike, the class-deactivator with the highest ordinal has the final decision. DeltaSpike itself doesn't deactivate an implementation, however, an add-on or a 3rd party portable CDI extension based on DeltaSpike (Core+) can use the concept to deactivate a default implementation of DeltaSpike in favour of its own implementation.

Attention: due to the ordinal feature of the low-level config approach it's possible that a class-deactivator with a higher ordinal, e.g. used in a concrete project, can re-activate a deactivated implementation.
Please note that you might have to deactivate the parts of the add-on or 3rd party CDI extension which relies on its own implementation. Therefore, you should be really careful with re-activation.) The implementation should be stateless because the result will be cached and as soon as everything is initialized the class-deactivators won't be used any longer.

ClassDeactivator¶

A class-deactivator allows to specify deactivated classes.

//This class needs to be configured via one of the supported config sources!
public class CustomClassDeactivator implements ClassDeactivator
{
    @Override
    public Boolean isActivated(Class<? extends Deactivatable> targetClass)
    {
        if (targetClass.equals(MyClass.class))
        {
            return Boolean.FALSE;
        }
        return null; //no result for the given class
    }
}

A class-deactivator will be resolved from the environment via the default resolvers or via a custom resolver which allows to use any type of configuration-format. (see org.apache.deltaspike.core.api.config.ConfigResolver). The key is the fully qualified name of the interface (org.apache.deltaspike.core.spi.activation.ClassDeactivator).

ConfigSource¶

[TODO]

ConfigSourceProvider¶

[TODO]

BaseConfigPropertyProducer¶

[TODO]

InterceptorStrategy¶

[TODO]

Global Alternative¶

There are several application servers (using CDI 1.0) which can't handle alternative CDI beans correctly (e.g. due to a too strict interpretation or a broken implementation). Therefore, DeltaSpike allows to use the std. @Alternative annotation and an additional config entry for DeltaSpike which allows to use the alternative implementation as a global alternative.

Std. CDI alternative implementation (without the required XML config)

public class CustomBean
{
}

@Alternative
//...
public class AlternativeCustomBean extends CustomBean
{
}

Instead of configuring the alternative in the beans.xml, a global alternative needs to be configured in /META-INF/apache-deltaspike.properties. CDI 1.1 should fix this issue and migrating to it means to remove the config entry for DeltaSpike again and move to the std. CDI config approach.

custom.CustomBean=custom.AlternativeCustomBean