Overview
Other MyFaces Extensions
- ExtVal
- Ext-Script
- [Orchestra]
- [Portlet Bridge]
Community
Development
Sponsorship
Your browser does not support iframes
...
The basic idea is to use out-of-the-box CDI concepts to customize CODI as well as to provide custom type-safe config implementations (if it is possible). That works in combination with OpenWebBeans (OWB) and with the first versions of Weld. To keep it short: it doesn't work with the newest versions of Weldversions between 1.1.0 and 1.1.3-SP1 of Weld (WELD-912 fixes it again). Therefore, it was required to introduce a custom concept. Even though the implementation for OWB (only) would be possible without a custom concept, you can use this optional concept for both CDI implementations. However, if you are using OWB you just need this information if you would like to use the alternative-config modules provided by CODI. In this case you just have to add the JARs to your project and you can use the alternative config e.g. based on a resource bundle.
...
If you would like to customize CODI in combination with Weld you just need the alternative-implementation module. If you are using OWB, you don't need this module only for this use-case (use @Specializes
or @Alternative
or @Specializes
provided by CDI).
If you would like to use one or more of the alternative config modules provided by CODI you need the config module as well as the alternative-implementation module. With OWB and Weld v1.1.3-SP1+ you could also skip the modules described in this page and implement your own alternative configuration concept based on @Alternative
or @Specializes
provided by CDI.
...
The module myfaces-extcdi-bundle-alternative-configuration
bundles all alternative configs provided by CODI in an all-in-one JAR file.
Use the single config modules or the all-in-one bundle but not both.
Sometimes it's required to activate and/or use other implementations provided by CODI or a custom implementation.
With OWB it's pretty simple - just annotate the class with @Alternative
, implement the same interfaces as the original class (btw. extend from the same abstract class) and activate the implementation in the beans.xml config of CDI. As an alternative approach you can use the @Specializes
annotation of CDI.
With Weld it's a bit more difficult. If the @Alternative
approach doesn't work, you have to do it manually via a CDI extension.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
public class VetoExtension implements Extension
{
protected void vetoDefaultImplementations(@Observes ProcessAnnotatedType<Object> processAnnotatedType)
{
Class beanClass = processAnnotatedType.getAnnotatedType().getJavaClass();
if(WindowHandler.class.isAssignableFrom(beanClass) &&
!AlternativeWindowHandler.class.isAssignableFrom(beanClass))
{
processAnnotatedType.veto();
}
}
}
public class AlternativeWindowHandler extends ServerSideWindowHandler
{
private static final long serialVersionUID = 6089519101832237681L;
}
|
As with every CDI extension you have to activate the VetoExtension
in META-INF/services/javax.enterprise.inject.spi.Extension