Jakarta EE WebProfile

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.

In the circumstances listed in [default_name], the rule for determining default name for an EJB session bean are defined in Default bean name for a session bean.

When running in Jakarta EE, a top-level Java class is a managed bean if it meets requirements described in [what_classes_are_beans] or if it is defined to be a managed bean by any other Jakarta EE specification and if

If a session bean is a stateful session bean:

The session bean is not required to have an EJB remove method in order for the container to destroy it.

If the application directly calls an EJB remove method of a contextual instance of a session bean that is a stateful session bean and declares any scope other than @Dependent, an UnsupportedOperationException is thrown.

If the application directly calls an EJB remove method of a contextual instance of a session bean that is a stateful session bean and has scope @Dependent then no parameters are passed to the method by the container. Furthermore, the container ignores the instance instead of destroying it when Contextual.destroy() is called, as defined in Lifecycle of EJB stateful session beans.

The unrestricted set of bean types for a session bean contains all local interfaces of the bean and their superinterfaces. If the session bean has a no-interface view, the unrestricted set of bean types contains the bean class and all superclasses. In addition, java.lang.Object is a bean type of every session bean.

Remote interfaces are not included in the set of bean types.

The resulting set of bean types for a session bean consists only of legal bean types, all other types are removed from the set of bean types.

A session bean does not require any special annotations apart from the component-defining annotation (or XML declaration) required by the EJB specification. The following EJBs are beans:

A bean class may also specify a scope, bean name, stereotypes and/or qualifiers:

A session bean class may extend another bean class:

If a bean class of a session bean X is annotated @Specializes, then the bean class of X must directly extend the bean class of another session bean Y. Then X directly specializes Y, as defined in [specialization].

If the bean class of X does not directly extend the bean class of another session bean, the container automatically detects the problem and treats it as a definition error.

For example, MockLoginActionBean directly specializes LoginActionBean:

The default name for a session bean is the unqualified class name of the session bean class, after converting the first character to lower case.

For example, if the bean class is named ProductList, the default bean name is productList.

A producer method declaration in an EJB session bean follows the rules defined in [declaring_producer_method] with the following addition:

A producer field declaration in an EJB session bean follows the rules defined in [declaring_producer_field] with the following addition:

A disposer method declaration in an EJB session bean follows the rules defined in [declaring_disposer_method] with the following addition:

A resource may be declared by specifying a Jakarta EE component environment injection annotation as part of a producer field declaration. The producer field may be static.

The injection annotation specifies the metadata needed to obtain the resource, entity manager, entity manager factory, remote EJB instance or web service reference from the component environment.

The bean type and qualifiers of the resource are determined by the producer field declaration.

If the producer field declaration specifies a bean name, the container automatically detects the problem and treats it as a definition error.

If the matching object in the Jakarta EE component environment is not of the same type as the producer field declaration, the container automatically detects the problem and treats it as a definition error.

The unrestricted set of bean types for a resource is determined by the declared type of the producer field, as specified by [producer_field_types].

The resulting set of bean types for a resource consists only of legal bean types, all other types are removed from the set of bean types.

When running in Jakarta EE, the container must extend the rules defined in [member_level_inheritance] and is also required to support specialization for EJB session beans as defined in Specializing a session bean.

When running in Jakarta EE, the container must extend the rules defined for managed beans in [declaring_selected_alternatives_application] to EJB session beans.

When running in Jakarta EE, the container must extend the rules defined for managed beans in [declaring_selected_alternatives_bean_archive] to EJB session beans.

When running in Jakarta EE, the container must extend the rules defined in [unsatisfied_and_ambig_dependencies] and must also validate all injection points of all Jakarta EE component classes supporting injection

When running in Jakarta EE, the container must extend the rules defined in [ambig_names] to names used in Expression Language.

When running in Jakarta EE, the container must extend the rules defined for managed beans in [instantiation] to EJB session beans.

When running in Jakarta EE, the container must extend the rules defined for managed beans in [fields_initializer_methods] to EJB session beans and to any other Jakarta EE component class supporting injection.

The container is also required to ensure that:

When running in Jakarta EE, the container must extend the rules defined for managed beans in [dependent_objects_destruction] to any other Jakarta EE component class supporting injection and perform destruction after the servlet destroy() method is called.

Interceptor and decorator instances associated with Jakarta EE components that are not considered beans (as defined by this specification) cannot obtain information about the beans they intercept and decorate (as defined in [bean_metadata]) and thus null is injected into relevant injection points.

When running in Jakarta EE, the container must extend the rules defined for bean in [dependent_objects] to Jakarta EE component class instance.

When running in Jakarta EE, the container must extend the rules defined for bean in [dependent_destruction] to Jakarta EE component class instance, and must also ensure that :

Suppose a Unified EL expression in a JSF or JSP page refers to a bean with scope @Dependent by its bean name. Each time the EL expression is evaluated:

Portable extensions that integrate with the container via Unified EL should also ensure that these rules are enforced.

When running in Jakarta EE, the container must extend the rules defined in [passivation_capable_dependency], and must also guarantee that:

When running in Jakarta EE, the container must extend the rules defined for managed beans in [passivation_validation] to EJB session beans.

When running in Jakarta EE the container must extend the rules defined in [request_context] and is also required to implement request context with the following rules.

The request context is active:

The request context is destroyed:

The payload of the event fired when the request context is initialized or destroyed is:

When running in Jakarta EE the container is required to implement session context with the following rules.

The session scope is active:

The session context is shared between all servlet requests that occur in the same HTTP session. The session context is destroyed when the HTTPSession times out, after all HttpSessionListener s have been called, and at the very end of any request in which invalidate() was called, after all filters and ServletRequestListener s have been called.

An event with qualifier @Initialized(SessionScoped.class) is synchronously fired when the session context is initialized. An event with qualifier @BeforeDestroyed(SessionScoped.class) is synchronously fired when the session context is about to be destroyed, i.e. before the actual destruction. An event with qualifier @Destroyed(SessionScoped.class) is synchronously fired when the session context is destroyed, i.e. after the actual destruction. The event payload is jakarta.servlet.http.HttpSession.

When running in Jakarta EE the container must extend the rules defined in [application_context] and is also required to implement application context with the following rules.

The application scope is active:

The application context is shared between all servlet requests, web service invocations, asynchronous invocation of an event observer, EJB remote method invocations, EJB asynchronous method invocations, EJB timeouts and message deliveries to message-driven beans that execute within the same application. The application context is destroyed when the application is shut down.

The payload of the event fired when the application context is initialized or destroyed is:

When running in Jakarta EE the container is required to implement conversation context with the following rules.

The conversation scope is active during all Servlet requests.

An event with qualifier @Initialized(ConversationScoped.class) is synchronously fired when the conversation context is initialized. An event with qualifier @BeforeDestroyed(ConversationScoped.class) is synchronously fired when the conversation is about to be destroyed, i.e. before the actual destruction. An event with qualifier @Destroyed(ConversationScoped.class) is synchronously fired when the conversation is destroyed, i.e. after the actual destruction. The event payload is:

The conversation context provides access to state associated with a particular conversation. Every Servlet request has an associated conversation. This association is managed automatically by the container according to the following rules:

Any conversation is in one of two states: transient or long-running.

All long-running conversations have a string-valued unique identifier, which may be set by the application when the conversation is marked long-running, or generated by the container.

If the conversation associated with the current Servlet request is in the transient state at the end of a Servlet request, it is destroyed, and the conversation context is also destroyed.

If the conversation associated with the current Servlet request is in the long-running state at the end of a Servlet request, it is not destroyed. The long-running conversation associated with a request may be propagated to any Servlet request via use of a request parameter named cid containing the unique identifier of the conversation. In this case, the application must manage this request parameter.

If the current Servlet request is a JSF request, and the conversation is in long-running state, it is propagated according to the following rules:

When no conversation is propagated to a Servlet request, or if a request parameter named conversationPropagation has the value none the request is associated with a new transient conversation.

All long-running conversations are scoped to a particular HTTP servlet session and may not cross session boundaries.

In the following cases, a propagated long-running conversation cannot be restored and reassociated with the request:

The conversation timeout, which may be specified by calling Conversation.setTimeout() is a hint to the container that a conversation should not be destroyed if it has been active within the last given interval in milliseconds.

If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type jakarta.enterprise.context.NonexistentConversationException.

The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type jakarta.enterprise.context.BusyConversationException.

When the create() method of a Bean object that represents an EJB stateful session bean that is called, the container creates and returns a container-specific internal local reference to a new EJB session bean instance. The reference must be passivation capable. This reference is not directly exposed to the application. When the create() method of a Bean object that represents an EJB stateful session bean that is called, the container creates and returns a container-specific internal local reference to a new EJB session bean instance. The reference must be passivation capable. This reference is not directly exposed to the application.

Before injecting or returning a contextual instance to the application, the container transforms its internal reference into an object that implements the bean types expected by the application and delegates method invocations to the underlying EJB stateful session bean instance. This object must be passivation capable.

When the destroy() method is called, and if the underlying EJB was not already removed by direct invocation of a remove method by the application, the container removes the EJB stateful session bean. The @PreDestroy callback must be invoked by the container.

Note that the container performs additional work when the underlying EJB is created and removed, as defined in [injection]

When the create() method of a Bean object that represents an EJB stateless session or singleton session bean is called, the container creates and returns a container-specific internal local reference to the EJB session bean. This reference is not directly exposed to the application.

Before injecting or returning a contextual instance to the application, the container transforms its internal reference into an object that implements the bean types expected by the application and delegates method invocations to the underlying EJB session bean. This object must be passivation capable.

When the destroy() method is called, the container simply discards this internal reference.

Note that the container performs additional work when the underlying EJB is created and removed, as defined in [injection]

When the create() method of a Bean object that represents a resource is called, the container creates and returns a container-specific internal reference to the Jakarta EE component environment resource, entity manager, entity manager factory, remote EJB instance or web service reference. This reference is not directly exposed to the application.

Before injecting or returning a contextual instance to the application, the container transforms its internal reference into an object that implements the bean types expected by the application and delegates method invocations to the underlying resource, entity manager, entity manager factory, remote EJB instance or web service reference. This object must be passivation capable.

The container must perform ordinary Jakarta EE component environment injection upon any non-static field that functions as a resource declaration, as defined by the Jakarta EE Platform and Jakarta Annotations specifications. The container is not required to perform Jakarta EE component environment injection upon a static field. Portable applications should not rely upon the value of a static field that functions as a resource declaration.

References to EJBs and web services are always dependent scoped and a new instance must be obtained for every injection performed.

For an entity manager associated with a resource definition, it must behave as though it were injected directly using @PersistenceContext.

When the destroy() method of a bean which represents a remote stateful EJB reference is called, the container will not automatically destroy the EJB reference. The application must explicitly call the method annotated @Remove. This behavior differs to that specified in Lifecycle of EJB stateful session beans for beans which represent a local stateful EJB reference

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.

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.

When running in Jakarta EE, the container must extend the rules defined in [interceptor] and must also ensure that

PRE_PASSIVATE, POST_ACTIVATE and AROUND_TIMEOUT InterceptorType values are linked to EJB lifecycle callback or timeout method.

A Jakarta EE container is required to provide a CDI provider that will allow access to the current container for any Jakarta EE application or Jakarta EE module which contains enabled beans.

Jakarta EE Components may obtain an instance of BeanManager from JNDI by looking up the name java:comp/BeanManager.

When running in Jakarta EE, the container must extend the rules defined in [process_annotated_type] to Jakarta EE component and EJB session bean classes.

When running in Jakarta EE, the container must also fire an event for every injection point of every Jakarta EE component class supporting injection that may be instantiated by the container at runtime, including every EJB session or message-driven bean.

When running in Jakarta EE, the container must also fire an event for every Jakarta EE component class supporting injection that may be instantiated by the container at runtime, including every EJB session or message-driven bean.

The container must extend the rules defined in [process_injection_target] for managed bean to EJB session bean and other Jakarta EE component class supporting injection.

For example, this observer decorates the InjectionTarget for all servlets.

When running in Jakarta EE, the container must extend the rules defined in [process_bean_attributes] to EJB session bean.

In addition to definition given in [process_bean] the following apply:

Resources are considered to be producer fields.

When running in Jakarta EE, the interface jakarta.enterprise.inject.spi.ProcessBean is also a supertype of jakarta.enterprise.inject.spi.ProcessSessionBean :

When running in Jakarta EE, the container must extend the rules defined in [bean_discovery_steps_full] and must also discover each EJB session bean.

When running in Jakarta EE, the container must extend the rules defined in [trimmed_bean_archive] and must ensure that EJB session beans are not removed from the set of discovered types.

The BeanManager implementation in Jakarta EE must also implement ELAwareBeanManager. All rules that apply to the BeanManager, as specified in [beanmanager] and The BeanManager object in Jakarta 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.

The method ELAwareBeanManager.getELResolver() returns the jakarta.el.ELResolver specified in Bean name resolution in EL expressions. This ELResolver is used to satisfy the rules defined in Bean names in Jakarta EE.

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 pseudo-scope and Unified EL are enforced by the container.