Interface Deployment
-
- All Known Subinterfaces:
CDI11Deployment
public interface Deployment
Represents a deployment of a CDI application.Background
Java EE defines a series of accessibility rules for classloading, which CDI extends to cover bean resolution. For example a bean in the war can inject a bean in an ejb-jar, but not vice-versa.
These rules are defined via the MANIFEST.MF Extension Mechanism Architecture and JAR File Specification.
Deployment structure representation
Weld will request the bean archive deployment structure during the bean discovery initialization step. After this step, CDI allows users to define bean's programmatically, possibly with bean classes from a deployment archive which is currently not a bean deployment archive. Weld will request the
BeanDeploymentArchive
for each programmatically usingloadBeanDeploymentArchive(Class)
. If any unknownBeanDeploymentArchive
s are loaded, before Weld proceeds to validating the deployment, the bean archive deployment structure will re-requested.The BeanDeploymentArchive tree represents the "logical structure" of the deployment; Given two archives A and B, which have a transitive closure of accessible archives A' and B', it allowable for the the archives A & B to be represented as a single BeanDeploymentArchive, assuming that A' and B' are bi-directionally accessible.
For an application deployed as an ear to a Java EE container, all library jars, EJB jars, rars and war WEB-INF/classes directories should be searched, and the bean deployment archive structure built.
For an application deployed as a war to a Java EE or Servlet container, all library jars and the WEB-INF/classes directory should be searched, and the bean deployment archive structure built.
For an application deployed in the SE environment, all library jars and classpath directories should be searched, and the bean deployment archive structure built. A single, logical deployment archive will be built for all beans and beans.xml files found on the classpath.
A Java EE example
Given an ejb-module A (not as part of an ear), an ear B (containing an ejb-jar C which uses the standard mechanism to reference module A, libraries F bundled in /lib, and a war D which references module C), and a war E (which references module A and bundles libraries G in /WEB-INF/lib) all deployed.
War E would have be able to resolve beans from ejb module A, libraries G, as well as other app server libraries. Furthermore, any libraries in G will be able to resolve beans in other libraries G as well as in ejb module A and war E. Ejb module A will not be able to resolve beans in war E or libraries G. It would be legal to represent any libraries G as a single logical BeanDeploymentArchive, also incorportating classes in war E.
War D would be able to resolve beans from from ejb module C, module A (transitively via C), libraries F, as well as other app server libraries. Ejb module C can resolve beans in libraries F as well as module A, but not beans in War D. Ejb module A cannot resolve beans in libraries F, module A or war D. It would be legal to represent libraries F as a single logical BeanDeploymentArchive.
- Author:
- Pete Muir
- See Also:
BeanDeploymentArchive
-
-
Method Summary
All Methods Instance Methods Abstract Methods Modifier and Type Method Description Collection<BeanDeploymentArchive>
getBeanDeploymentArchives()
Get the bean deployment archives which are part of this deployment and adjacent to it in the deployment archive graph.Iterable<Metadata<jakarta.enterprise.inject.spi.Extension>>
getExtensions()
Specifies the extensions this deployment should call observer methods on.ServiceRegistry
getServices()
Get the services available to this deploymentBeanDeploymentArchive
loadBeanDeploymentArchive(Class<?> beanClass)
Load theBeanDeploymentArchive
containing the given class.
-
-
-
Method Detail
-
getBeanDeploymentArchives
Collection<BeanDeploymentArchive> getBeanDeploymentArchives()
Get the bean deployment archives which are part of this deployment and adjacent to it in the deployment archive graph. This should include all Java EE modules such as WARs, EJB jars and RARs. Cycles in the accessible BeanDeploymentArchive graph are allowed. If a cycle is detected by Weld, it will be automatically removed by Web Beans. This means any implementor of this interface don't need to worry about circularities.- Returns:
- the accessible bean deployment archives
-
loadBeanDeploymentArchive
BeanDeploymentArchive loadBeanDeploymentArchive(Class<?> beanClass)
Load theBeanDeploymentArchive
containing the given class. If the deployment archive containing the given class is not currently a bean deployment archive, it must be added to the bean deployment archive graph and returned. If the deployment archive is currently a bean deployment archive it should be returned. If beanClass is the bean class of an EJB session bean, anEjbDescriptor
for the bean must be returned byBeanDeploymentArchive.getEjbs()
.- Parameters:
beanClass
- the bean class to load- Returns:
- the
BeanDeploymentArchive
containing the bean class - Throws:
IllegalArgumentException
- if the beanClass is not visisble to the current deployment
-
getServices
ServiceRegistry getServices()
Get the services available to this deployment- Returns:
- the services available
-
getExtensions
Iterable<Metadata<jakarta.enterprise.inject.spi.Extension>> getExtensions()
Specifies the extensions this deployment should call observer methods on. JSR-299 specifies that extensions should be loaded using Service Providers from the JAR File specification Weld delegates this task to the container, allowing the container to programatically alter the extensions registered. To load extensions, the container could use theServiceLoader
available in the JDK (since Java 6). In pre Java 6 environments, the container must provide the ServiceLoader itself. We provide an example Service Loader here.- Returns:
- the extensions to call observer methods on, or an empty list if there are no observers
-
-