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.
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.
