This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Overview

Other MyFaces Extensions

Community

Development

Sponsorship

Unknown macro: {iframe}

Your browser does not support iframes

Child pages
  • Core Config and SPI
Skip to end of metadata
Go to start of metadata

Intro

This page introduces the most important extension points for application developers. More special information is available at the DevDoc.

Custom Project Stages

It's possible to provide custom project stage implementations.
Therefore, you have to provide an implementation of the ProjectStageHolder interface.
In this class you nest the custom project-stage implementations which have to be public static final class and it's required to extend ProjectStage.
It's required to provide a public static final instance even though, you won't use it directly.

ProjectStageHolder for custom project stage implementations
public class CustomProjectStageHolder implements ProjectStageHolder
{
    public static final class CustomProjectStage extends ProjectStage
    {
        private static final long serialVersionUID = 1029094387976167179L;
    }

    public static final CustomProjectStage CustomProjectStage = new CustomProjectStage();
}

Configure your custom ProjectStageHolder in META-INF/services/org.apache.myfaces.extensions.cdi.core.api.projectstage.ProjectStageHolder. The file has to provide the fully qualified class name of the custom implementation of the ProjectStageHolder interface.

Usage of a custom project stage
ProjectStage customProjectStage;
customProjectStage = ProjectStage.valueOf("CustomProjectStage");
//or
customProjectStage = CustomProjectStageHolder.CustomProjectStage;
//or
@ProjectStageActivated(CustomProjectStageHolder.CustomProjectStage.class)

Deactivating default implementations

CDI provides the mechanism of @Alternative (as well as @Specializes) implementations. As soon as MyFaces CODI provides a default implementation as CDI bean, it's possible to provide a custom implementation via @Alternative (or @Specializes) (+ the corresponding std. CDI config). However, some CDI artifacts like CDI-Extensions (javax.enterprise.inject.spi.Extension) and Interceptors (javax.interceptor.Interceptor) don't support the mechanism for providing alternative implementations. Therefore, MyFaces CODI allows to create a custom implementation of the ClassDeactivator interface (or AbstractClassDeactivator).

Implementing a custom Class-Deactivator
public class CustomClassDeactivation extends AbstractClassDeactivator
{
    protected void deactivateClasses()
    {
        addDeactivatedClass(DefaultImpl.class);
        //...
    }
}

Environment config options provides details about out-of-the-box environment-config options.

Instead of listing all classes which support such a deactivation, you can list all implementations of the Deactivatable interface (via your IDE).

Hint

If you would like to filter additional beans, you can provide a custom javax.enterprise.inject.spi.Extension and observe javax.enterprise.inject.spi.ProcessAnnotatedType for calling #veto on an implementation.

API/Impl

Since the API of MyFaces CODI is separated, you can implement your custom implementation-module for an existing api-module. However, MyFaces CODI is a community project. So it's a good idea to donate improvements of any kind instead of permanently forking the implementation.

Deactivating default implementations - Details

Deactivatable

This interface allows to use a common interface (similar to a marker interface) for deactivatable framework-artifacts which can’t be deactivated by calling #veto (like pre-configured CDI extensions provided by MyFaces CODI -> usually this interface isn't intended for CDI beans). By default everything is pre-configured to support zero-config. It isn’t required but suggested to use this interface because it allows to find such classes easily.
Users just have to be aware of this concept to deactivate parts of MyFaces CODI. It isn't mandatory, but suggested to use ClassDeactivation#isClassActivated for implementing Deactivatable#isActivated.
Since it is just a common interface which allows users to find deactivatable framework-classes easily, Deactivatable#isActivated has to be called manually by the implementing class.

ClassDeactivation

This class allows to evaluate, if a given class is deactivated for a specific application. ClassDeactivation aggregates all configured ClassDeactivator implementations. A class gets deactivated, if one of the available ClassDeactivator implementations returns this class.

ClassDeactivator

A ClassDeactivator can be configured for your environment (see Environment config options). An implementation of this interface has to implement #getDeactivatedClasses which returns all (framework-)classes which shouldn't get used. Since it is the equivalent of #veto for pre-configured framework-classes, every class which gets returned usually implements Deactivatable.

AbstractClassDeactivator

This abstract class is a helper which allows to use #addDeactivatedClass and therefore an easier handling for adding classes which should be deactivated.

Core Config

CodiCoreConfig is the type-safe config provided by the core. It's possible to provide a custom (type-safe) implementation with std. CDI concepts like @Specializes, @Alternative or ProcessAnnotatedType#veto. As an alternative CODI provides an alternative configuration module as well as an alternative implementation module which allows to use resource-bundles to configure the framework via property files.

The JavaDoc provides further details about the config-entries.

Core SPI

The core of CODI provides a very basic SPI:

  • BeanEntryFactory (and BeanEntry)
  • EditableAccessDecisionVoterContext
  • WindowContextManager
  • InterceptorStrategy

Custom implementations can be provided via the std. @Alternative (or @Specializes) mechanism provided by CDI.

BeanEntryFactory and BeanEntry

A BeanEntryFactory is responsible for creating instances of BeanEntry. A BeanEntry is used internally for storing conversation scoped beans.

WindowContextManager

A WindowContextManager is responsible for managing the current WindowContext. This interface is a basic (and read-only) implementation which is independent of a concrete view-technology. Modules like the JSF module can use it as base interface. The JSF module provides an EditableWindowContextManager SPI which allows to manage the WindowContext in a more specific manner which might be related to peculiarities of a concrete view-technology. If you don't need further APIs of the WindowContextManager, you don't need #getCurrentWindowContext in your application. You can directly inject the current WindowContext via @Inject.

EditableAccessDecisionVoterContext

This interface allows to provide a custom AccessDecisionVoterContext implementation which will be used by CODI.

InterceptorStrategy

CODI allows to provide custom implementations for all interceptors provided by the framework. This interface is just the base interface for all interceptor interfaces. You can create custom implementations via providing a @Specialized (or @Alternative) implementation.

  • No labels