Subsume PR 838 and rebase with HEAD of main

specification/pom.xml

@@ -20,7 +20,7 @@
     <parent>
         <groupId>org.eclipse.ee4j</groupId>
         <artifactId>project</artifactId>
-        <version>1.0.7</version>
+        <version>1.0.9</version>
         <relativePath/>
     </parent>
     <modelVersion>4.0.0</modelVersion>

specification/src/main/asciidoc/platform/ApplicationProgrammingInterface.adoc

@@ -226,6 +226,12 @@ language. Jakarta Enterprise Beans 2.x API group.]
 |Y
 |REQ
 
+|Managed Beans (Deprecated)
+|Y
+|Y
+|Y
+|REQ
+
 |Messaging
 |Y
 |Y

specification/src/main/asciidoc/platform/Platform.adoc

@@ -23,6 +23,8 @@ include::ServiceProviderInterface.adoc[]
 
 include::CompatibilityMigration.adoc[]
 
+include::../shared-includes/IntegrationRequirements.adoc[]
+
 include::FutureDirections.adoc[]
 
 include::PreviousVersionDeploymentDescriptors.adoc[]

specification/src/main/asciidoc/platform/RelatedDocuments.adoc

@@ -68,6 +68,7 @@ _Jakarta™ Managed Beans Specification, Version 2.0_. Available at: _https://ja
 
 _Jakarta™ Interceptors Specification, Version 2.1_. Available at: _https://jakarta.ee/specifications/interceptors/2.1_
 
+[[cdi-spec]]
 _Jakarta™ Contexts and Dependency Injection Specification, Version 4.0_. Available at: _https://jakarta.ee/specifications/cdi/4.0_
 
 _Jakarta™ Dependency Injection Specification, Version 2.0_. Available at: _https://jakarta.ee/specifications/dependency-injection/2.0_

specification/src/main/asciidoc/platform/cdi-ee-spec/decorators_ee.adoc

@@ -0,0 +1,12 @@
+[[decorators_ee]]
+
+== Decorators in Jakarta EE
+
+When running in Jakarta EE, the container must extend the rules defined for managed beans in <<decorators>> to EJB session beans.
+
+[[decorator_bean_ee]]
+
+=== Decorator beans in Jakarta EE
+
+Decorators of an EJB session bean must comply with the bean provider programming restrictions defined by the EJB specification.
+Decorators of an EJB stateful session bean must comply with the rules for instance passivation and conversational state defined by the EJB specification.

specification/src/main/asciidoc/platform/cdi-ee-spec/definition_ee.adoc

@@ -0,0 +1,90 @@
+[[concepts_ee]]
+
+== CDI Extended Concepts for Jakarta EE
+
+When running in Jakarta EE, the container must extend the concepts defined in <<concepts>> with:
+
+* A Jakarta EE component is a _bean_ if the lifecycle of its instances may be managed by the container according to the lifecycle context model defined in <<contexts>>
+* Contextual instances of a bean may be used in EL expressions that are evaluated in the same context
+* For some Jakarta EE components - like environment resources, defined in <<resources>>  - the developer provides only the annotations and the bean implementation is provided by the container.
+
+[[capabilities_ee]]
+
+=== Functionality provided by the container to the bean in Jakarta EE
+
+When running in Jakarta EE, the container must extend the capabilities defined in <<capabilities>>, by providing:
+
+* scoped resolution by bean name when used in a Unified EL expression, as defined by <<name_resolution>>.
+
+[[bean_types_ee]]
+
+=== Bean types for Jakarta EE component
+
+As managed beans, EJB session beans may have multiple bean types depending on their client-visible types.
+For instance, this session bean has only the local interfaces `BookShop` and `Auditable`, along with `Object`, as bean types, since the bean class is not a client-visible type.
+
+[source, java]
+----
+@Stateful 
+public class BookShopBean 
+        extends Business 
+        implements BookShop, Auditable { 
+    ... 
+}
+----
+
+The rules for determining the (unrestricted) set of bean types for Jakarta EE components are defined in  <<session_bean_types>> and <<resource_types>>.
+
+[[scopes_ee]]
+
+=== Scopes
+
+Jakarta EE components such as servlets, EJBs and JavaBeans do not have a well-defined _scope_.
+These components are either:
+
+* _singletons_, such as EJB singleton session beans, whose state is shared between all clients,
+* _stateless objects_, such as servlets and stateless session beans, which do not contain client-visible state, or
+* objects that must be explicitly created and destroyed by their client, such as JavaBeans and stateful session beans, whose state is shared by explicit reference passing between clients.
+
+CDI scopes add to Jakarta EE these missing well-defined lifecycle context as defined in <<scopes>>.
+
+[[builtin_scopes_ee]]
+
+==== Built-in scope types in Jakarta EE
+
+When running in Jakarta EE, the implementations of the `@RequestScoped`, `@ApplicationScoped` and `@SessionScoped` annotations provided by the container, represent the standard scopes defined by the Java Servlets specification.
+
+
+[[default_bean_discovery_ee]]
+=== Default bean discovery mode for Jakarta EE
+
+When running in Jakarta EE, If the _bean discovery mode_ is `annotated`, the container must extend the rules defined in <<default_bean_discovery>> with:
+
+* bean classes of EJB sessions beans, are discovered, and
+* producer methods that are on an EJB session bean are discovered, and
+* producer fields that are on an EJB session bean are discovered, and
+* disposer methods that are on an EJB session bean are discovered, and
+* observer methods that are on an EJB session bean are discovered.
+
+
+[[names_ee]]
+=== Bean names in Jakarta EE
+
+A bean with a name may be referred to by its name in Unified EL expressions.
+
+There is no relationship between the bean name of an EJB session bean and the EJB name of the bean.
+
+Bean names allow the direct use of beans in JSP or JSF pages.
+For example, a bean with the name `products` could be used like this:
+
+[source, xml]
+----
+<h:outputText value="#{products.total}"/>
+----
+
+[[default_name_ee]]
+
+==== Default bean names for EJB session beans
+
+In the circumstances listed in <<default_name>>, the rule for determining default name for an EJB session bean are defined in <<session_bean_name>>.
+

specification/src/main/asciidoc/platform/cdi-ee-spec/el.adoc

@@ -0,0 +1,46 @@
+[[el]]
+== Integration with Unified EL
+
+[[el_resolution]]
+=== Bean name resolution in EL expressions
+
+The container must provide a Unified EL `ELResolver` to the servlet engine and JSF implementation that resolves bean names using the rules of name resolution defined in <<name_resolution>> and resolving ambiguities according to <<ambig_names>>.
+
+* If a name used in an EL expression does not resolve to any bean, the `ELResolver` must return a null value.
+* Otherwise, if a name used in an EL expression resolves to exactly one bean, the `ELResolver` must return a contextual instance of the bean, as defined in <<contextual_instance>>.
+
+[[el_support]]
+=== Unified EL integration API
+
+Since CDI version 4.1, the Unified EL integration API, which is part of the `BeanManager` API, is deprecated.
+The relevant methods are placed in a new interface `jakarta.enterprise.inject.spi.el.ELAwareBeanManager`, which is present in a new supplemental CDI API artifact: `jakarta.enterprise:jakarta.enterprise.cdi-el-api`.
+
+==== Obtaining `ELAwareBeanManager`
+
+The `BeanManager` implementation in Jakarta EE must also implement `ELAwareBeanManager`.
+All rules that apply to the `BeanManager`, as specified in <<beanmanager>> and <<beanmanager_ee>>, also apply to `ELAwareBeanManager`.
+
+It follows that the container provides a built-in bean with bean type `ELAwareBeanManager`, scope `@Dependent` and qualifier `@Default`, which is a passivation capable dependency as defined in <<passivation_capable_dependency>>.
+It also follows that an `ELAwareBeanManager` may be obtained by using `CDI.current().getBeanManager()` and casting.
+
+The EL-related methods of `ELAwareBeanManager` may be called at any time during the execution of the application.
+
+==== Obtaining the `ELResolver`
+
+The method `ELAwareBeanManager.getELResolver()` returns the `jakarta.el.ELResolver` specified in <<el_resolution>>.
+This `ELResolver` is used to satisfy the rules defined in <<names_ee>>.
+
+[source, java]
+----
+public ELResolver getELResolver();
+----
+
+==== Wrapping a Unified EL `ExpressionFactory`
+
+The method `ELAwareBeanManager.wrapExpressionFactory()` returns a wrapper `jakarta.el.ExpressionFactory` that delegates `MethodExpression` and `ValueExpression` creation to the given `ExpressionFactory`.
+When a Unified EL expression is evaluated using a `MethodExpression` or `ValueExpression` returned by the wrapper `ExpressionFactory`, the rules defined in <<dependent_scope_el>> are enforced by the container.
+
+[source, java]
+----
+public ExpressionFactory wrapExpressionFactory(ExpressionFactory expressionFactory);
+----

specification/src/main/asciidoc/platform/cdi-ee-spec/events_ee.adoc

@@ -0,0 +1,24 @@
+[[events_ee]]
+
+== Events in Jakarta EE
+
+[[observer_methods_ee]]
+
+=== Observer methods in EJB session beans
+
+An observer method may also be a non-abstract method of an EJB session bean class.
+It must be either a business method exposed by a local business interface of the EJB or a static method of the bean class.
+
+[[observes_ee]]
+
+==== Declaring an observer method in an EJB
+
+If a non-static method of a session bean class has a parameter annotated `@Observes` or `@ObservesAsync`, and the method is not a business method exposed by a local business interface of the EJB, the container automatically detects the problem and treats it as a definition error.
+
+[[observer_method_invocation_context_ee]]
+
+==== Observer method invocation context in Jakarta EE
+
+When running in Jakarta EE, the container must extend the rules defined in <<observer_method_invocation_context>> and must also ensure that all kinds of observers are called in the same client security context as the invocation of `Event.fire()` or `Event.fireAsync()`.
+
+The transaction and security contexts for a business method exposed by a local business interface of an EJB session bean also depend upon the transaction attribute and `@RunAs` descriptor, if any.