Specification: Jakarta Managed Beans Version: 2.0 Status: Final Release Release: October 15, 2020
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.
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.
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.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.
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:
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.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.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.
Appendix A: Revision History
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
javaxpackage references to thejakartanamespace. -
Updated “Related Documents" for the updated Specifications in Jakarta EE 9.
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