...

Usage for Users

Activation

ClassDeactivator

A class-deactivator allows to specify deactivated classes which can't be deactivated via std. CDI mechanisms. All classes which implement Deactivatable in-/directly, can be deactivated with this mechanism. For all other classes/beans, you can use the veto mechanism provided by CDI.

A ClassDeactivator will be resolved from the environment via the default resolvers or via a custom resolver which allows to use any type of configuration-format. An easy way to configure it permanently is to use the service-loader approach. Furthermore, AbstractClassDeactivator is a convenience class which allows an easier implementation.

ProjectStageActivated

This annotation allows to activate beans for a special project-stage. It's possible to use one of the out-of-the-box project-stages or a custom typesafe project-stage.

ProjectStageActivated

This annotation allows to activate beans for a special project-stage. It's possible to use one of the out-of-the-box project-stages or a custom typesafe project-stage.

@Alternative
@ProjectStageActivated(ProjectStage.UnitTest.class)
public class TestServiceMockImpl implements Service
{
  //...
}

@Alternative
@ProjectStageActivated({ProjectStage.UnitTestDevelopment.class})
public class TestServiceMockImplDevServiceMockImpl implements Service
{
  //...
}

@Alternative
@ProjectStageActivated({ProjectStage.Development.class})
public class DevServiceMockImpl implements Service
{
  //...
}

ExpressionActivated

This annotation allows to activate beans based on expressions. OutTo configure a project-stage you can use the key: org.apache.myfaces.extensions.cdi.ProjectStage and configure it for your environment (see the out-of-the-box simple conditions are supported. The values will be resolved from the environment via the default resolvers or via a custom resolver which allows to use any type of configuration-format. An easy way to configure it permanently is e.g. myfaces-extcdi.properties or for more dynamic use-cases, it's possible to use system-properties.-config options).
If there is no CODI project-stage configured and it's a JSF application, CODI will re-use the project-stage configured for JSF (currently the web.xml approach isn't supported because in our opinion it's a wrong and quite risky place to configure it - however, with a custom ConfiguredValueResolver it's possible to resolve the project-stage configuration from any kind of configuration-source).

ExpressionActivated

This annotation allows to activate beans based on expressions. Out-of-the-box simple conditions are supported. The values will be resolved from the environment via the default resolvers or via a custom resolver which allows to use any type of configuration-format. An easy way to configure it permanently is e.g. myfaces-extcdi.properties or for more dynamic use-cases, it's possible to use system-properties.

@ExpressionActivated("db==dev-db

@ExpressionActivated("db==dev-db")
public class TestDataCreator
{
  //...
}

or

@ExpressionActivated("db!=prod-db;db==*")
public class TestDataCreator
{
  //...
}


or

@ExpressionActivated("db!=prod-db;db==*")
public class TestDataCreator
{
  //...
}

'*'*' allows to ensure that there is a configured value. So the 2nd example ensures that there is a value for 'db' but it isn't 'prod'.

...

@ExpressionActivated(value = "${environment.stage eq 'test'}", interpreter = CustomInterpreter.class)
public class TestDataCreator
{
  //...
}

Config

The core of CODI provides base implementations which are used to provide a testable, pluggable and type-safe config. If it is possible this CDI based config approach is used to configure the framework (esp. the SPI). This approach decouples the logical config entries from the config-source. That means it's possible to switch e.g. between Java Config (values are directly encoded in config classes), property files, db table/s, xml (e.g. web.xml) and every other format which can be used for a config.

Out-of-the-box CODI uses typesafe configuration. Furthermore, there is an alternative configuration module which allows to resolve configure values from myfaces-extcdi.properties or via a custom ConfiguredValueResolver from any other configuration format/source.

CodiConfig

All modules which have CODI-Core as dependency use use the CodiConfig interface as marker interface for their config-classes. So it's easy to find all configurations. All methods annotated with ConfigEntry provide a config-value which is used by CODI. During bootstrapping all values are logged (it's possible to deactivate this behaviour by config see CodiCoreConfig#isConfigurationLoggingEnabled). If you provide custom custom values and you face any issue, please also post the configuration to the mailing-list.

CodiCoreConfig

//...
}

Config

The core of CODI provides base implementations which are used to provide a testable, pluggable and type-safe config. If it is possible this CDI based config approach is used to configure the framework (esp. the SPI). This approach decouples the logical config entries from the config-source. That means it's possible to switch e.g. between Java Config (values are directly encoded in config classes), property files, db table/s, xml (e.g. web.xml) and every other format which can be used for a config.

Out-of-the-box CODI uses typesafe configuration. Furthermore, there is an alternative configuration module which allows to resolve configure values from myfaces-extcdi.properties or via a custom ConfiguredValueResolver from any other configuration format/source.

CodiConfig

All modules which have CODI-Core as dependency use use the CodiConfig interface as marker interface for their config-classes. So it's easy to find all configurations. All methods annotated with ConfigEntry provide a config-value which is used by CODI. During bootstrapping all values are logged (it's possible to deactivate this behaviour by config see CodiCoreConfig#isConfigurationLoggingEnabled). If you provide custom custom values and you face any issue, please also post the configuration to the mailing-list.

CodiCoreConfig

This config contains the basic configuration for the core as well as common config entries for multiple modules.

Environment-Config Options

In some cases it isn't possible to use CDI based configuration. Esp. for parts which have to be active before the CDI container gets bootstrapped.
For such cases CODI uses an extensible configuration approach. By default it supports configuration via:

• ServiceLoader (if classes have to be configured which implement an interface or extend an abstract class)
• System properties
• JNDI
• Resource Bundle (properties file with the name myfaces-extcdi.properties)

However, with a custom ConfiguredValueResolver it's possible to resolve the project-stage configuration from any kind of configuration-sourceThis config contains the basic configuration for the core as well as common config entries for multiple modules.

Logging

To avoid external dependencies, CODI uses the JDK Logger. However, CDI often requires serializable beans - therefore CODI provides a serializable wrapper for the JDK Logger.

...