Your browser does not support iframes
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);
//...
}
}
You can provide a custom ClassDeactivator via JNDI (name: java:comp/env/myfaces-codi/ClassDeactivator) or VM parameter (-D org.apache.myfaces.extensions.cdi.ClassDeactivator) or via a CODI Java-API ( ClassDeactivation#setClassDeactivator).
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.
The core of CODI provides a very basic and generic SPI for conversations:
Custom implementations can be provided via the std. @Alternative (or @Specializes) mechanism provided by CDI.
A WindowContextManager is responsible for managing the current WindowContext. This interface is the base (and read-only) implementation for EditableWindowContextManager (which is provided by the JSF module). 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.
A BeanEntryFactory is responsible for creating instances of BeanEntry. A BeanEntry is used internally for storing conversation scoped beans.
