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 interface allows to introduce a custom configuration approach/format for all parts which can't be configured with std. CDI mechanisms. The resolver takes a ConfiguredValueDescriptor which specifies the key as well as the target type. It's allowed to return simple instances like strings, integers,... or more complex custom types. CODI uses this approach to integrate different lookup approaches which allow to use different config sources/types with a central approach.
This interface as well as AbstractAttributeAware provide common methods for all CODI artifacts which have to manage key/value pairs. They were introduced to avoid different implementations for the same concept.
This is an optional placeholder which has to be used, if it is required to use a string to specify the name of a page. Since it isn't type-safe you should avoid it.
This generic interface should be used if it is required to implement an interpreter. It's used e.g. for the @ExpressionActivated.
This abstract class just provides common/shared methods for other abstract implementations which aren't directly related. It only provides protected methods.
Interface of an optional context which allows to get the current state as well as the results of the security check. The state (AccessDecisionState) exposes the following information:
This broadcaster is more an internal mechanism but it has to be part of the api module because the BeanManagerProvider has to use it. You don't have to use it directly. It's possible to register a StartupEventBroadcaster for broadcasting custom events.
This event gets triggered as soon as the environment is up and running. The core just provides the event but doesn't fire it because the bootstrapping state depends on the target environment. E.g. the JSF module of CODI triggers it quite lazily but before the first request.
Register a custom StartupEventBroadcaster for integrating a broadcaster which gets invoked before the StartupEvent gets fired.
Attention: There is no guarantee that CDI has been bootstrapped.
However, a StartupEventBroadcaster allows to do it (see the controlled bootstrapping add-on).
Hint
The usage of @InvocationOrder is supported.
The InvocationOrder annotation allows to order the invocation of several artifacts provided and/or supported by CODI. This comparator is used by different CODI modules to perform this ordering. Furthermore, it can be used for custom artifacts/add-ons/... which should use/support InvocationOrder as well.
This util-class provides common functionality for handling classes. It is used by different CODI modules (also by the API classes of the core), therefore it has to be part of the core. However, there is no guarantee that the methods of this class will exist or behave the same over time.
The ServiceProvider is a custom and extensible alternative for the ServiceLoader of Java 1.6+. It allows to use CODI also with Java 1.5 and to customize it.
The usage is quite simple: ServiceProvider.loadServices(MyService.class). The config of the service-implementations is the same as with the ServiceLoader.
It's possible to provide a custom implementation. Since it's a quite special use-case we skip the details. Information about providing a custom implementations are available in ServiceProvider#resolveImplementation. To change classloading for the services, it's e.g. possible to provide a custom ServiceProviderContext and return a custom classloader via ServiceProviderContext#getClassLoader. Furthermore, the EditableServiceProviderContext interface allows to customize the behaviour of the ServiceProvider. E.g. it allows to invoke post-construct logic, filter service implementations,... The default implementations supports @InvocationOrder for services, dependency injection and filtering via the de-activation mechanism provided by CODI.
This interface allows e.g. to collect different instances of the same type and creating a placeholder which delegates to all those instances. It's up to the implementation if the found instances are filtered based on a rule.
This interface provides information about CODI. Currently it provides the version and in case of snapshots the SVN revision which was the foundation to build the snapshot.
This runtime-exception is used by CODI to wrap and re-throw checked exceptions if CODI can't handle them in a meaningful way.
