Your browser does not support iframes
...
Project stages allow to use implementations depending on the current environment. E.g. you can implement a bean which creates sample-data for unit tests which gets activated only in case of project-stage UnitTest.
Besides custom project-stages it's possible to use the following pre-defined project-stages:
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. Besides the out-of-the-box project-stages it's possible to implement custom but type-safe project-stages which will be exposed by CODI.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
@Inject private ProjectStage projectStage; //... boolean isDevProjectStage = ProjectStage.Development.equals(this.projectStage); |
...
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@javax.enterprise.inject.Alternative @ProjectStageActivated(ProjectStage.UnitTest.class) public class TestServiceMockImpl implements Service { //... } |
...
To 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 environment-config options). Static configuration files like web.xml and property files aren't supported by default because in our opinion it's a wrong and quite risky place to configure it independent of the environment - however, with a custom ConfiguredValueResolver it's possible to resolve the project-stage configuration from any kind of configuration-source.
If there is no CODI project-stage configured and it's a JSF application, CODI will re-use the project-stage configured for JSF.
...
's a JSF application, CODI will re-use the project-stage configured for JSF (that's possible because JSF project-stages are a logical subset of CODI project-stages and project stages which are identical also use the same name and will be mapped automatically).
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 (see out-of-the-box environment-config options) or via a custom ConfiguredValueResolver which allows to use any type of configuration-format.
...
To avoid external dependencies, CODI uses the JDK Logger. However, CDI often requires serializable beans and JDK loggers aren't serializable - therefore CODI provides a serializable wrapper for the JDK Logger.
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
@Inject private BeanManager beanManager; //or BeanManager beanManager = BeanManagerProvider.getInstance().getBeanManager(); |
In some cases (e.g. in custom CDI extensions or classes which aren't managed by CDI), it isn't possible to inject the BeanManager. Therefore, it's possible to use BeanManagerProvider.getInstance().getBeanManager().
...
CODI provides multiple hooks for the startup. Usually it's enough to observe the StartupEvent fired by CODI during the startup-process as soon as the target environment is up and running. In case of JSF this event is fired lazily. If you need to execute custom logic before CODI gets active, you should have a look at the dev guide (see StartupEventBroadcaster).
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
@ProjectStageActivated({Development.class, IntegrationTest.class})
public class SampleDataStartupObserver
{
protected void createSampleData(@Observes StartupEvent startupEvent, UserRepository userRepository)
{
User user = new User("Demo", "User");
userRepository.save(user);
}
}
|
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
CustomAnnotation annotation = DefaultAnnotation.of(CustomAnnotation.class); |
...
This annotation can be used as marker annotation for artifacts which aren't managed by CDI. If such arifacts are supported by CODI (the documentation of every module shows such artifacts) and annotated with this annotation, it's possible to use dependency injection for fields. Furthermore, this annotation can be used as CDI qualifier.
...
This annotation isn't used by CODI modules. It's a common annotation which can be used as marker annotation or qualifier by CODI add-ons. So they don't have to introduce their own marker annotation.
...
This interface is a marker interface for all interfaces which contain bean names (used by @Named @javax.inject.Named within CODI). So it's very easy to find beans which can be used in EL expressions.
...
This interface specifies all beans of the core which can be resolved by name.
...
Artifacts which support this annotation can be sorted. The default order is 1000. Artifacts with a lower ordinal will be called before artifacts with a higher ordinal. If there is an artifact which is supported by CODI but doesn't provide an explicit order, it will be moved at the end of the list.
...
The following artifacts define base contracts which can be used by CODI modules or any other custom modules which would like to build on the well known contracts provided by CODIby CODI modules or any other custom modules which would like to build on the well known contracts provided by CODI.
The information provided by this section is quite general because this part of the Core just specifies a quite abstract contract which is independent of a concrete technology.
Please have a look at the specific modules which use those contracts (esp. the JSF module), if you need more concrete information.
This package part of the Core provides the basic concepts which allow to provide a type-safe config for views. CODI currently uses it in the JSF module for typesafe navigation as well as multiple inheritance for type-safe page-configs.
ViewConfig as well as DefaultErrorView are the foundations for the concept and will be explained in the documentation of the JSF module. However, it's possible to use it for other UI technologies as well.
...
This annotation can be used as interceptor to restrict calls to methods to one or more views. Modules are also allowed to use it as marker annotation to link a bean to a view by annotating the bean with it and pointing to the view(s). In this case a module is allowed to store the information internally and remove the interceptor dynamically to avoid performance impacts.
...
This annotation allows to provide custom meta-data. Just annotate a custom annotation with it. A module like the JSF module has to provide a resolver to query it. A query might return multiple results of the same type. If it doesn't make sense to have multiple results, you can use @ViewMetaData(override=true).
...
This navigation handler defines how to navigate with view-configs. Currently it's used by all JSF modules to allow implicit navigation based on the view-configs.
...
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).
...
This isn't the std. CDI annotation!
With this annotation it's possible to scope beans in parallel or grouped conversations which are way more powerful that the std. conversation of CDI 1.
...
Since it's a generic concept, it's also possible to provide an implementation for other view-technologies.
...
With this annotation it's possible to save beans until the first request of a new view doesn't access it. It's a very convenient scope e.g. for wizard which can't be interrupted.
...
Since it's a generic concept, it's also possible to provide an implementation for other view-technologies.
...
This annotation is comparable to a session per window. Compared to the scopes mentioned above, all beans will be removed at the same point in time.
...
This interface is independent of JSF. However, currently you need the JSF 1.x or 2.x module to use an out-of-the-box implementation of it. Further, details and examples are available in the documentation of the CODI-JSF-module.
...
This annotation allows to group conversations with a type-safe mechanism.
...
Since it's a generic concept, it's also possible to provide an implementation for other view-technologies.
...
This annotation allows to prevent a navigation to a view which require an existing conversation.
...
Since it's a generic concept, it's also possible to provide an implementation for other view-technologies.
...
This method-interceptor allows to close the conversation(-group) of the current bean or an explicitly specified group after the invocation of the method or in case of a specified exception.
...
The AbstractAccessDecisionVoter allows an easier implementation.
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
@Page(navigation = REDIRECT)
public interface Pages extends ViewConfig
{
@Secured(LoginAccessDecisionVoter.class)
public interface Secure extends Pages
{
public @Page class InternalPage implements Secure {}
}
}
|
...
