public interface Deployment
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.
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 using
loadBeanDeploymentArchive(Class). If any unknown
BeanDeploymentArchives 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.
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.
|Modifier and Type||Method and Description|
Get the bean deployment archives which are part of this deployment and adjacent to it in the deployment archive graph.
Specifies the extensions this deployment should call observer methods on.
Get the services available to this deployment
BeanDeploymentArchive loadBeanDeploymentArchive(Class<?> beanClass)
BeanDeploymentArchivecontaining 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, an
EjbDescriptorfor the bean must be returned by
ServiceLoaderavailable 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.
Copyright © 2008–2017. All rights reserved.