All Downloads are FREE. Search and download functionalities are using the official Maven repository.

org.jboss.weld.bootstrap.spi.Deployment Maven / Gradle / Ivy

There is a newer version: 3.0.0.Alpha1
Show newest version
/*
 * JBoss, Home of Professional Open Source
 * Copyright 2010, Red Hat, Inc., and individual contributors
 * by the @authors tag. See the copyright.txt in the distribution for a
 * full listing of individual contributors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * http://www.apache.org/licenses/LICENSE-2.0
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.jboss.weld.bootstrap.spi;

import java.util.Collection;
import java.util.ServiceLoader;

import javax.enterprise.inject.spi.Extension;

import org.jboss.weld.bootstrap.api.ServiceRegistry;
import org.jboss.weld.ejb.spi.EjbDescriptor;

/**
 * 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 {@link BeanDeploymentArchive} for each programmatically using * {@link #loadBeanDeploymentArchive(Class)}. If any unknown {@link BeanDeploymentArchive}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. *

* * @see BeanDeploymentArchive * * @author Pete Muir * */ public interface Deployment { /** * 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. * * @return the accessible bean deployment archives * */ Collection getBeanDeploymentArchives(); /** * Load the {@link 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 {@link EjbDescriptor} for the bean must be returned by * {@link BeanDeploymentArchive#getEjbs()}. * * @param beanClass the bean class to load * @return the {@link BeanDeploymentArchive} containing the bean class * @throws IllegalArgumentException if the beanClass is not visisble to the current deployment */ BeanDeploymentArchive loadBeanDeploymentArchive(Class beanClass); /** * Get the services available to this deployment * * @return the services available */ ServiceRegistry getServices(); /** * 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 {@link 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. * * @return the extensions to call observer methods on, or an empty list if there are no observers */ Iterable> getExtensions(); }




© 2015 - 2024 Weber Informatics LLC | Privacy Policy