Your browser does not support iframes
...
The core of MyFaces CODI consists of two modules (api and impl). This site just contains information about the api module. Basically it Basically the core just provides some basic interfaces of CODI which are used across modules (and can be used also for custom portable extensions), common annotations and useful utils like @ProjectStageActivated, an injectable logger and much more.
The core (both modules) is the only required module for using MyFaces CODI. All other modules are optional. That means you can chose the modules you really need! Most of the other modules depend on the core. The only exception is the message module which is self-contained.
...
| Note | ||
|---|---|---|
| ||
If you would like to test CODI or you need all modules provided by CODI, you can use an all-in-one JAR file. |
This event gets fired as soon as the whole environment (e.g. CDI, JSF, CODI) is ready. In case of JSF this event is fired lazily.
Register a custom StartupEventBroadcaster for integrating a broadcaster which gets invoked before the StartupEvent was fired.
Attention: There is no guarantee that CDI has been bootstrapped.
However, a StartupEventBroadcaster allows to do it (see the controlled bootstrapping add-on).
| Note | ||
|---|---|---|
| ||
The usage of @InvocationOrder is supported. |
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.
| 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. |
View config is a type-safe approach to configure a view. Currently the basic infrastructure is used by the JSF module to allow a type-safe navigation and View-Controller (and it's planned to provide further features after the first alpha of CODI).
The core provides a pluggable and type-safe approach for using project stages in a project (it's also used within the framework). Furthermore, @ProjectStageActivated allows to use e.g. implementations annotated with javax.enterprise.inject.Alternative for specific project-stages.
| Warning | ||
|---|---|---|
| ||
Currently the config is bound to the project stage implementation of JSF (since the impl. uses strings you won't see the dependency at compile time). However, we will change that. If you already use it, please be aware that the names for the config will change. |
All interfaces and annotations which are independent from the concrete UI technology are provided by the core. E.g. the concepts of CODI conversations aren't bound to JSF. So the core defines the basic API for CODI conversations. Instead of providing a framework adapter (like MyFaces Orchestra does), CODI hosts the specific implementation in the corresponding module. Currently the UI modules of CODI are just for JSF. However, it would be possible to provide a module e.g. for (plain) servlets. Such a module can use the APIs provided by the core (which are independent of JSF and its concepts).
The core provides a bunch of central qualifiers. Some of them are used to decouple CODI modules and others are used to provide special features. E.g. @Advanced allows the injection of advanced implementations provided by CODI, if JEE supports the injection of the default implementation.
There is no additional dependency (just the CDI API).
See CODI Modules - Overview and Setup
See Core UsageThe core also provides some utils and tools which are useful for CDI based applications (and/or for the framework itself).
