Jakarta Managed Beans
Jakarta EE Platform Team, https://projects.eclipse.org/projects/ee4j.jakartaee-
platform
2.0, October 15, 2020
Table of Contents
Copyright. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê2
Eclipse Foundation Specification License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê3
Disclaimers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê3
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê5
1.1. What Are Managed Beans?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê5
1.2. Why Managed Beans? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê5
1.3. Acknowledgements for Version 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê6
2. Managed Beans Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê7
2.1. Basic Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê7
2.1.1. Component Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê7
2.1.2. Naming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê7
2.1.3. Lifecycle and Resource Injection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê8
2.1.4. Threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê8
2.1.5. Interceptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê8
2.2. Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê8
2.2.1. Component Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê8
2.2.2. Naming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê9
2.2.3. Lifecycle and Resource Injection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê9
2.2.4. Threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê9
2.2.5. Interceptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê9
Appendix A: Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê10
A.1. Changes in Final Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê10
A.1.1. Editorial Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê10
A.2. Changes in Milestone Release Draft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê10
A.2.1. Editorial Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê10
Appendix B: Related Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê11
Specification: Jakarta Managed Beans
Version: 2.0
Status: Final Release
Release: October 15, 2020
Jakarta Managed Beans
Final Release Jakarta Managed BeansÊÊÊ 1
Copyright
Copyright (c) 2018, 2020 Eclipse Foundation.
Copyright
2 ÊÊÊJakarta Managed Beans Final Release
Eclipse Foundation Specification License
By using and/or copying this document, or the Eclipse Foundation document from which this statement
is linked, you (the licensee) agree that you have read, understood, and will comply with the following
terms and conditions:
Permission to copy, and distribute the contents of this document, or the Eclipse Foundation document
from which this statement is linked, in any medium for any purpose and without fee or royalty is
hereby granted, provided that you include the following on ALL copies of the document, or portions
thereof, that you use:
link or URL to the original Eclipse Foundation document.
All existing copyright notices, or if one does not exist, a notice (hypertext is preferred, but a textual
representation is permitted) of the form: "Copyright (c) [$date-of-document] Eclipse Foundation,
Inc. <<url to this license>>"
Inclusion of the full text of this NOTICE must be provided. We request that authorship attribution be
provided in any software, documents, or other items or products that you create pursuant to the
implementation of the contents of this document, or any portion thereof.
No right to create modifications or derivatives of Eclipse Foundation documents is granted pursuant to
this license, except anyone may prepare and distribute derivative works and portions of this document
in software that implements the specification, in supporting materials accompanying such software,
and in documentation of such software, PROVIDED that all such works include the notice below.
HOWEVER, the publication of derivative works of this document for use as a technical specification is
expressly prohibited.
The notice is:
"Copyright (c) [$date-of-document] Eclipse Foundation. This software or document includes material
copied from or derived from [title and URI of the Eclipse Foundation specification document]."
Disclaimers
THIS DOCUMENT IS PROVIDED "AS IS," AND THE COPYRIGHT HOLDERS AND THE ECLIPSE
FOUNDATION MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING,
BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY
PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD
PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
THE COPYRIGHT HOLDERS AND THE ECLIPSE FOUNDATION WILL NOT BE LIABLE FOR ANY DIRECT,
INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR
THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.
Disclaimers
Final Release Jakarta Managed BeansÊÊÊ 3
The name and trademarks of the copyright holders or the Eclipse Foundation may NOT be used in
advertising or publicity pertaining to this document or its contents without specific, written prior
permission. Title to copyright in this document will at all times remain with copyright holders.
Disclaimers
4 ÊÊÊJakarta Managed Beans Final Release
Chapter 1. Introduction
This specification defines Managed Beans for the Jakarta™ EE Platform.
1.1. What Are Managed Beans?
Managed Beans are container-managed objects with minimal requirements, otherwise known under
the acronym “POJOs” (Plain Old Java Objects). They support a small set of basic services, such as
resource injection, lifecycle callbacks and interceptors. Other, more advanced, aspects will be
introduced in companion specifications, so as to keep the basic model as simple and as universally
useful as possible.
1.2. Why Managed Beans?
Managed Beans offer a lightweight component model aligned with the rest of the Jakarta EE Platform.
By supporting the common resource injection and lifecycle services, Managed Beans fit well into the
Jakarta EE programming model. At the same time, their lightweight nature makes them a natural
starting point to encapsulate application functionality, with the knowledge that they can be morphed
into more powerful components if and when the need occurs. In this sense, they can be seen as a
Jakarta EE platform-enhanced version of the JavaBeans component model found on the Java™ SE
platform.
It won’t be missed by the reader that Managed Beans have a precursor in the homonymous facility
found in the Jakarta Server Faces technology. Indeed, the web tier has seen ample use of lightweight
components, tied together with a variety of mechanisms. Managed Beans as defined in this
specification represent a generalization of those found in Jakarta Server Faces; in particular, Managed
Beans can be used anywhere in a Jakarta EE application, not just in web modules.
In introducing Managed Beans, we also have a longer-term goal: to provide a common foundation for
the different kinds of components that exist in the Jakarta EE platform, allowing us to align them
better and reconcile their differences as much as possible.
Many of the distinctions that exist between component types in Jakarta EE are historical in nature. In
hindsight, the platform might have adopted a more uniform model where components start their
existence as undistinguished Java objects and grow into more powerful entities by drawing on
container-provided services. The annotation-based programming model introduced in version 5 of the
Jakarta EE Platform naturally lends itself to such an interpretation.
Managed Beans offers us a way to carry out such a refactoring of the existing components over time
while offering developers some genuinely useful functionality in the short term.
1.1. What Are Managed Beans?
Final Release Jakarta Managed BeansÊÊÊ 5
1.3. Acknowledgements for Version 1.0
This specification was created under the Java Community Process as JSR-316. The spec leads for the
JSR-316 Expert Group were Bill Shannon (Sun Microsystems, Inc.) and Roberto Chinnici (Sun
Microsystems, Inc.). The expert group included the following members: Florent Benoit (Inria), Adam
Bien (Individual), David Blevins (Individual), Bill Burke (Red Hat Middleware LLC), Larry Cable (BEA
Systems), Bongjae Chang (Tmax Soft, Inc.), Rejeev Divakaran (Individual), Francois Exertier (Inria), Jeff
Genender (Individual), Antonio Goncalves (Individual), Jason Greene (Red Hat Middleware LLC), Gang
Huang (Peking University), Rod Johnson (SpringSource), Werner Keil (Individual), Michael Keith
(Oracle), Wonseok Kim (Tmax Soft, Inc.), Jim Knutson (IBM), Elika S. Kohen (Individual), Peter
Kristiansson (Ericsson AB), Changshin Lee (NCsoft Corporation), Felipe Leme (Individual), Ming Li
(TongTech Ltd.), Vladimir Pavlov (SAP AG), Dhanji R. Prasanna (Google), Reza Rahman (Individual),
Rajiv Shivane (Pramati Technologies), Hani Suleiman (Individual).
We’d also like to acknowledge the work done by the JSF ™ expert group over the years to define a
notion of “managed beans” in that specification.
1.3. Acknowledgements for Version 1.0
6 ÊÊÊJakarta Managed Beans Final Release
Chapter 2. Managed Beans Definition
This chapter defines the Managed Beans component model.
The presentation is organized in two sections. The first one describes the basic component model for
Managed Beans. This is the minimal set of requirements for Managed Beans implementations. The
second section describes how specifications that build on this one may extend the basic model to
support more advanced functionality.
For example, in the basic component model, Managed Beans must provide a no-argument constructor,
but a specification that builds on Managed Beans, such as CDI (JSR-299), can relax that requirement
and allow Managed Beans to provide constructors with more complex signatures, as long as they
follow some well-defined rules. Similarly, in the basic model, a Managed Bean component must be
declared using the ManagedBean annotation, but other specifications are allowed to alter this
requirement, e.g. to provide a purely XML-based way to turn a class into a Managed Bean.
2.1. Basic Model
2.1.1. Component Definition
A Managed Bean can be declared by annotating its class with the jakarta.annotation.ManagedBean
annotation.
A Managed Bean must not be: a final class, an abstract class, a non-static inner class.
A Managed Bean may not be serializable, unlike a regular JavaBean component.
Managed Bean implementations must support Managed Beans that have a no-argument constructor.
2.1.2. Naming
A Managed Bean may optionally have a name, a String .
The name can be specified using an element of the ManagedBean annotation.
Ê@ManagedBean(cart)
Êpublic class ShoppingCart \{ ... }
Managed Bean names must be unique within a Jakarta EE module. It is an error if a Jakarta EE module
contains a Jakarta Enterprise Bean component and a Managed Bean with the same name.
For each named Managed Bean, Jakarta EE containers must make available the following entries in
JNDI, using the same naming scheme used for Jakarta Enterprise Bean components.
In the application namespace:
2.1. Basic Model
Final Release Jakarta Managed BeansÊÊÊ 7
Êjava:app/<module-name>/<bean-name>
In the module namespace of the module containing the Managed Bean:
Êjava:module/<bean-name>
Jakarta EE applications may obtain a new instance of a Managed Bean by looking up the corresponding
names in JNDI or by using resource injection. See Chapter 5 of the Jakarta EE Platform specification for
more details.
2.1.3. Lifecycle and Resource Injection
Managed Beans may use the jakarta.annotation.PostConstruct and jakarta.annotation.PreDestroy
annotations to identify methods to be called back by the container at the appropriate points in the
bean’s lifecycle.
In a Jakarta EE implementation, a Managed Bean may use any of the resource injection functionality
laid out in Chapter 5 of the Jakarta EE Platform specification, “Resources, Naming and Injection“. A
Managed Bean does not have its own component-scoped “java:comp” namespace. For this reason,
Managed Beans should define resources in the “java:module” namespace or above. JNDI lookup
operations from a method defined on a Managed Bean will use the naming context of that method’s
caller.
2.1.4. Threading
Method invocations on a Managed Bean execute in the same thread as the caller.
2.1.5. Interceptors
A Managed Bean may use interceptors as defined in the Interceptor specification.
2.2. Extensions
Specifications that build on the present one (called here an “extension specification”) may modify
some of the aspects of the basic model, as detailed in the rest of this section.
2.2.1. Component Definition
An extension specification may provide ways to declare a Managed Bean that go beyond those in the
Basic Model Component Definition.
An extension specification may allow a Managed Bean to declare constructors with complex
signatures, thus dropping the requirement that a no-argument constructor be present.
2.2. Extensions
8 ÊÊÊJakarta Managed Beans Final Release
2.2.2. Naming
An extension specification may offer alternative ways to name a Managed Bean, e.g. as a side-effect of
placing some other annotation on the bean class, but, if specified, the ManagedBean(”…”) annotation
takes priority, and with it the rules in the Basic Model Naming.
Of course an extension specification may also introduce one or more additional namespaces in which
some or all Managed Beans get registered, either with the Managed Bean name defined in the Basic
Model Naming or with an independently defined name.
2.2.3. Lifecycle and Resource Injection
An extension specification may define its own lifecycle model, adding e.g. pooling, sharing of instances,
etc., beyond the basic model described in the Basic Model Lifecycle and Resource Injection.
An extension specification may allow Managed Beans to have their own “java:comp” namespace.
2.2.4. Threading
An extension specification may add its own threading requirements, overriding any requirements set
in the Basic Model Threading.
For example, invocations on a [proxy for] a Managed Bean may be performed using a different thread
than the caller’s.
2.2.5. Interceptors
An extension specification may add its own interceptor-like facilities to the predefined one.
For example, an extension specification may allow declaring type-safe interceptors, defined using a
different set of APIs than those in the jakarta.interceptor package.
2.2. Extensions
Final Release Jakarta Managed BeansÊÊÊ 9
Appendix A: Revision History
A.1. Changes in Final Release
A.1.1. Editorial Changes
Changed the name of the generated Specifications to match the short name for the component
(managed-beans).
A.2. Changes in Milestone Release Draft
A.2.1. Editorial Changes
Initial contribution of the Managed Beans Specification source.
Changed most instances of "Java EE" to "Jakarta EE", except where the previous technology was
clearly the target.
Modified references to Oracle™-related items per the documented guidelines.
Updated javax package references to the jakarta namespace.
Updated “Related Documents" for the updated Specifications in Jakarta EE 9.
A.1. Changes in Final Release
10 ÊÊÊJakarta Managed Beans Final Release
Appendix B: Related Documents
This specification refers to the following documents. The terms used to refer to the documents in this
specification are included in parentheses.
Jakarta™ EE Platform Specification Version 9. Available at: https://jakarta.ee/specifications/platform/9
Java™ Platform, Standard Edition, v8 API Specification (Java SE specification). Available at:
https://docs.oracle.com/javase/8/docs/
Jakarta™ Enterprise Beans Specification, Version 4.0. Available at: https://jakarta.ee/specifications/
enterprise-beans/4.0
Jakarta™ Server Faces Specification, Version 3.0. Available at: https://jakarta.ee/specifications/faces/3.0
Jakarta™ Annotations Specification, Version 2.0. Available at: https://jakarta.ee/specifications/
annotations/2.0
Jakarta™ Contexts and Dependency Injection Specification, Version 3.0. Available at: https://jakarta.ee/
specifications/cdi/3.0
Appendix B: Related Documents
Final Release Jakarta Managed BeansÊÊÊ 11