Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

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.

Providing other alternative implementations

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
java
java
titleWorkaround for alternative implementations in combination with Weld

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