David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] modified the document: "Java EE Implementation Technical Requirements" To view the document, visit: http://community.jboss.org/docs/DOC-16195 -------------------------------------------------------------- h5. 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. h5. JNDI h6. 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. h5. Managed Beans and Java EE (non-CDI) Injection h6. 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. h6. 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. h5. EJB: Singleton Beans h6. 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 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+ 5. + + h5. EJB: Stateless Session Beans h6. 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 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. h5. EJB: Stateful Session Beans h6. 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 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) h5. EJB: Message-Driven Beans (MDBs) h6. 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. Each MDB service shall have a dependency upon the +endpoint activation+ service that corresponds to its 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. h5. Class Loading and Modularization of EE Deployments h4. Important Note! Please forward all questions and comments about this documentation to mailto:jboss-as7-dev@lists.jboss.org jboss-as7-dev(a)lists.jboss.org. Comments on this article have been disabled. -------------------------------------------------------------- Create a new document in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]