Overview
Other MyFaces Extensions
- ExtVal
- Ext-Script
- [Orchestra]
- [Portlet Bridge]
Community
Development
Sponsorship
Your browser does not support iframes
...
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.
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.
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.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
@Alternative
@ProjectStageActivated(ProjectStage.UnitTest.class)
public class TestServiceMockImpl implements Service
{
//...
}
|
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
Code Block | ||||||
| ||||||
@Alternative @ProjectStageActivated({ProjectStage.UnitTestDevelopment.class}) public class TestServiceMockImplDevServiceMockImpl implements Service { //... } | ||||||
Code Block | java | java | ||||
title | Alternative implementation activated for Project-Stage Development | |||||
@Alternative
@ProjectStageActivated({ProjectStage.Development.class})
public class DevServiceMockImpl implements Service
{
//...
}
|
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).
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.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
@ExpressionActivated("db==dev-db | ||||||
Code Block | ||||||
java | java | |||||
title | Alternative implementation activated based on a configured value | @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'.
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
@ExpressionActivated(value = "${environment.stage eq 'test'}", interpreter = CustomInterpreter.class)
public class TestDataCreator
{
//...
}
|
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.
Note | ||
---|---|---|
| ||
Since the config is based on CDI mechanisms, it isn't possible to use it for all configurations. There are some very basic configurations (e.g. deactivation of specific CODI features), which have to be accessible before CDI is fully initialized. |
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.
//...
}
|
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.
Note | ||
---|---|---|
| ||
Since the config is based on CDI mechanisms, it isn't possible to use it for all configurations. There are some very basic configurations (e.g. deactivation of specific CODI features), which have to be accessible before CDI is fully initialized. |
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.
This config contains the basic configuration for the core as well as common config entries for multiple modules.
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:
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.
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.
...