Version 4
    Purpose

    The purpose of this document is to specify the ways in which JBoss AS integrates with the implementations of various Java EE specifications.  It does not specify details of the implementations themselves unless the correct behavior in JBoss AS depends on the specific behavior of the corresponding EE specification implementation.

    JNDI
    Services
    1. Each JNDI binding into the "java:" space shall have a corresponding MSC service.  This includes programmatic bindings.
      1. Services corresponding to bindings in the "java:app" space shall be named "jboss.naming.context.java.app.binding.appname.contextname", where appname is the EE application name and contextname is the full JNDI context name, sans the leading "app/".
      2. Services corresponding to bindings in the "java:module" space shall be named "jboss.naming.context.java.module.binding.appname.modulename.contextname", where appname is the EE application name, modulename is the EE module name, and contextname is the full JNDI context name, sans the leading "module/".
      3. Services corresponding to bindings in the "java:comp" space shall be named "jboss.naming.context.java.comp.binding.appname.modulename.componentname.contextname", where appname is the EE application name, modulename is the EE module name, componentname is the EE component name, and contextname is the full JNDI context name, sans the leading "comp/".
      4. Services corresponding to bindings in the "java:global" or any other space shall be named "jboss.naming.context.java.global.binding.contextname" where contextname is the full JNDI context name (including the leading "global/" if present).
      5. In cases like the WAR case where one or more of these namespaces are aliased, the most general namespace is used.  For example, in a WAR deployment the "java:comp" namespace and the "java:module" namespace are equivalent, so bindings into "java:comp" should be aliased into the "java:module" area with the service named as if the binding had gone into the "java:module" area.
      6. In cases where an EE deployment unit is added outside of an application deployment (EAR), the application name is considered to be equal to the module name; in this case the preceding aliasing rule does not apply.
    2. Any binding service created from within, or on behalf of, a deployment unit shall have a dependency upon that deployment unit's "install" phase service, and shall be removed (with the corresponding bindings undone) with the deployment unit when the "install" phase service is removed.  In this way, all bindings which were established on behalf of a deployment unit will be removed when the deployment unit is undeployed.
    Interceptors
    1. System-wide EJB interceptors should be specified in the domain configuration, except as specified below.
    2. By default, our standard interceptors should be enabled, however each standard interceptor will have a corresponding domain element which can be used to disable that interceptor if so desired.
    3. Custom interceptors can be specified in the appropriate subsystem by a combination of module name and class name.
    Managed Beans and Java EE (non-CDI) Injection
    Services
    1. Each Managed Bean has a service which represents the availability of that Managed Bean.
      1. The service value is, or allows access to, a factory which produces proxy instances which access instances of that managed bean as defined in the EE and Managed Bean specifications.
      2. The service shall be named "jboss.managed-bean.appname.modulename.name", where appname is the EE application name, modulename is the EE module name, and name is the name of the managed bean.
    2. The Managed Bean service depends on the JNDI binding service for its JNDI binding, if it is a named Managed Bean.
    3. The Managed Bean service has a dependency upon the JNDI binding service corresponding to the mappedName (whether it is generated or specified) of each of its injected resources.
    4. For unnamed (type-based) resource injections, a dependency is introduced from the injection's mappedName JNDI binding service to the service corresponding to the container-managed class (container-managed class is defined in EE.5.2.5).
      1. The class must be visible from the current module, including via a "Class-Path:" or modular dependency.
      2. The list of visible container-managed classes is built and maintained during deployment on the deployment unit context, assembled from information collected from all immediate dependencies.
    5. For named (JNDI-based) resource injections where the source name is in the "java:" JNDI protocol space, a dependency is introduced from the injection's mappedName JNDI binding service to the service corresponding to the JNDI binding of the resource.
    6. Resources on any interceptor classes associated with the Managed Bean are treated as dependencies the same way as resources associated with the Managed Bean itself.
    Object Factory and Proxy
    1. The object factory bound into JNDI shall only yield a valid instance if the corresponding Managed Bean service is UP.  If the service is not UP, the object factory should block.  If the service is failed, or if a dependency is failed or missing, then an exception should be thrown.  A blocking object factory can be unblocked by a transition to either the UP state or a failed/missing state.

     

    EJB: Singleton Beans
    Services
    1. Each Singleton EJB has a corresponding MSC service.
      1. The service value is, or allows access to, a factory which produces proxy instances to the singleton instance. (TODO: does this return the same proxy every time or a new one every time?)
      2. The service shall be named "jboss.ejb.singleton.appname.modulename.beanname" where appname is the EE application name, modulename is the EE module name, and beanname is the name of the EJB.
    2. If the singleton is an eager singleton, the service shall have an implicit service dependency on all other EJB and Servlet components' services (with the exception of other eager EJB singletons, which must be explicitly depended on).  This is because eager singletons presume to have immediate access to any other services bound into JNDI.  (Note: perhaps we can somehow use lazy proxies to achieve this behavior instead, if this dependency becomes a problem)
    3. Each Singleton EJB service shall have a dependency on services corresponding to the JNDI bindings of any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this EJB configuration.
    4. TODO: Determine what rules (if any) pertain to service dependencies of things injected via CDI

     

    EJB: Stateless Session Beans
    Services
    1. Each declared Stateless Session Bean has a corresponding MSC service.
      1. The service value is, or allows access to, a factory which produces proxy instances to an instance of this EJB, according to the rules of the EJB specification implementation.
      2. The service shall be named "jboss.ejb.stateless.appname.modulename.beanname" where appname is the EE application name, modulename is the EE module name, and beanname is the name of the EJB.
    2. Each Stateless Session Bean EJB service shall have a dependency on services corresponding to  the JNDI bindings of any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this EJB configuration.
    3. The instance pools utilized by the Stateless Session Bean portion of the EJB subsystem(s) shall be configurable via the domain model.

     

    EJB: Stateful Session Beans
    Services
    1. Each declared Stateful Session Bean has a corresponding MSC service.
      1. The service value is, or allows access to, a factory which produces proxy instances to an instance of this EJB, according to the rules of the EJB specification implementation.
      2. The service shall be named "jboss.ejb.stateful.appname.modulename.beanname" where appname is the EE application name, modulename is the EE module name, and beanname is the name of the EJB.
    2. Each Stateful Session Bean EJB service shall have a dependency on services corresponding to the JNDI bindings of any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this EJB definition.
    3. In order to meet the requirements for proper JPA integration, construction of stateful EJB instances shall happen at the time of the original lookup, as opposed to being constructed lazily.
    4. In order to meet the requirements for proper CDI integration, the expiration policy or lifecycle of the EJB must be controllable externally in cases where CDI manages the overall session lifecycle.
    5. When constructing a stateful EJB from any context, the transaction, persistence, and security context from the constructing thread must be propagating to the thread which is constructing and initializing the EJB instance.  This is most easily accomplished by reusing the same thread for this purpose.
    6. The domain model for the Stateful Session Bean portion of the EJB subsystem(s) shall allow configuration of:
      1. Cache size
      2. Default timeouts (idle and passivation)
      3. Passivation (enable or disable)

     

    EJB: Message-Driven Beans (MDBs)
    Services
    1. Each declared MDB has a corresponding MSC service.
      1. The service shall be named "jboss.ejb.mdb.appname.modulename.beanname" where appname is the EE application name, modulename is the EE module name, and beanname is the name of the MDB.
      2. When started, the service shall cause endpoint activation to occur on the resource adapter as well as initiating the management of MDB instances.
      3. When stopped, the service shall cause endpoint deactivation to occur.
    2. Each MDB service shall have a dependency upon the service that corresponds to the JCA Resource Adapter defined by the MDB configuration.
    3. Each MDB service shall have a dependency upon services corresponding to any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this MDB definition.

     

    JCA: Message Inflow
    Services
    1. Each JCA Resource Adapter (RA) shall have a corresponding MSC service.
      1. (service name req.)
    2. Each JCA RA service shall have a dependency on services corresponding to the JNDI bindings of any resources injected via JNDI.
    Class Loading and Modularization of EE Deployments

     

    Important Note!

    Please forward all questions and comments about this documentation to jboss-as7-dev@lists.jboss.org.  Comments on this article have been disabled.