Class BeanManagerProvider
- All Implemented Interfaces:
jakarta.enterprise.inject.spi.Extension
BeanManager by registering the current BeanManager in an extension
and making it available via a singleton factory for the current application.
This is really handy when you need to access CDI functionality from places where no injection is available.
If a simple but manual bean lookup is needed, it's easier to use the BeanProvider.
As soon as an application shuts down, the reference to the BeanManager is removed.
Usage:
BeanManager bm = BeanManagerProvider.getInstance().getBeanManager();
Attention: This approach is intended for use in user code at runtime. If BeanManagerProvider is used during
Container boot (in an Extension), non-portable behaviour results. During bootstrapping, an Extension shall
@Inject BeanManager to get access to the underlying BeanManager (see e.g. cleanupFinalBeanManagers(jakarta.enterprise.inject.spi.AfterDeploymentValidation)).
This is the only way to guarantee that the right BeanManager is obtained in more complex Container scenarios.
-
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionvoidcleanupFinalBeanManagers(jakarta.enterprise.inject.spi.AfterDeploymentValidation adv) By cleaning the final BeanManager map after the deployment gets validated, premature loading of information from JNDI is prevented in cases where the container might not be fully setup yet.voidcleanupStoredBeanManagerOnShutdown(jakarta.enterprise.inject.spi.BeforeShutdown beforeShutdown) Cleanup on container shutdown.jakarta.enterprise.inject.spi.BeanManagerThe activeBeanManagerfor the current application (currentClassLoader).static BeanManagerProviderReturns the current provider instance which provides access to the currentBeanManager.static booleanisActive()Indicates whether theBeanManagerProviderhas been initialized.voidsetBeanManager(jakarta.enterprise.inject.spi.AfterBeanDiscovery afterBeanDiscovery, jakarta.enterprise.inject.spi.BeanManager beanManager) It doesn't really matter which of the system events is used to obtain the BeanManager, butAfterBeanDiscoveryhas been chosen since it allows all events which occur after theAfterBeanDiscoveryto use theBeanManagerProvider.
-
Constructor Details
-
BeanManagerProvider
public BeanManagerProvider()
-
-
Method Details
-
isActive
public static boolean isActive()Indicates whether theBeanManagerProviderhas been initialized. Usually it's not necessary to call this method in application code. It's useful e.g. for other frameworks to check if DeltaSpike and the CDI container in general have been started.- Returns:
- true if the BeanManagerProvider is ready to be used
-
getInstance
Returns the current provider instance which provides access to the currentBeanManager.- Returns:
- the singleton BeanManagerProvider
- Throws:
IllegalStateException- if theBeanManagerProviderisn't ready to be used. That's the case if the environment isn't configured properly and therefore theAfterBeanDiscoveryhasn't been called before this method gets called.
-
setBeanManager
public void setBeanManager(@Observes jakarta.enterprise.inject.spi.AfterBeanDiscovery afterBeanDiscovery, jakarta.enterprise.inject.spi.BeanManager beanManager) It doesn't really matter which of the system events is used to obtain the BeanManager, butAfterBeanDiscoveryhas been chosen since it allows all events which occur after theAfterBeanDiscoveryto use theBeanManagerProvider.- Parameters:
afterBeanDiscovery- event which we don't actually use ;)beanManager- the BeanManager we store and make available.
-
getBeanManager
public jakarta.enterprise.inject.spi.BeanManager getBeanManager()The activeBeanManagerfor the current application (currentClassLoader). This method will throw anIllegalStateExceptionif the BeanManager cannot be found.- Returns:
- the current BeanManager, never
null - Throws:
IllegalStateException- if the BeanManager cannot be found
-
cleanupFinalBeanManagers
public void cleanupFinalBeanManagers(@Observes jakarta.enterprise.inject.spi.AfterDeploymentValidation adv) By cleaning the final BeanManager map after the deployment gets validated, premature loading of information from JNDI is prevented in cases where the container might not be fully setup yet. This might happen if the BeanManagerProvider is used in an extension during CDI bootstrap. This should be generally avoided. Instead, an injected BeanManager should be used in Extensions and propagated using setters. In EARs with multiple webapps, each WAR might get a different Extension. This depends on the container used. -
cleanupStoredBeanManagerOnShutdown
public void cleanupStoredBeanManagerOnShutdown(@Observes jakarta.enterprise.inject.spi.BeforeShutdown beforeShutdown) Cleanup on container shutdown.- Parameters:
beforeShutdown- CDI shutdown event
-