Package org.jboss.weld.bootstrap.spi

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 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.

    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 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 the BeanDeploymentArchive 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, an EjbDescriptor for the bean must be returned by BeanDeploymentArchive.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 the ServiceLoader 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