Overview
Other MyFaces Extensions
- ExtVal
- Ext-Script
- [Orchestra]
- [Portlet Bridge]
Community
Development
Sponsorship
Your browser does not support iframes
This page introduces the most important extension points for application developers. More special information is available at the DevDoc.
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.
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.
ProjectStage customProjectStage; customProjectStage = ProjectStage.valueOf("CustomProjectStage"); //or customProjectStage = CustomProjectStageHolder.CustomProjectStage; //or @ProjectStageActivated(CustomProjectStageHolder.CustomProjectStage.class)
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
).
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.
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.
The core of CODI provides a very basic SPI:
Custom implementations can be provided via the std. @Alternative
(or @Specializes
) mechanism provided by CDI.
A BeanEntryFactory
is responsible for creating instances of BeanEntry
. A BeanEntry
is used internally for storing conversation scoped beans.
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
.
This interface allows to provide a custom AccessDecisionVoterContext
implementation which will be used by CODI.
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.