+1 for removal
I very much agree with removing jakarta.annotation.ManagedBean and would also like to see jakarta.faces.bean.ManagedBean removed as well.
Unfortunately, I’ve seen application developers using jakarta.annotation.ManagedBean because they think that is required to make something a CDI bean, so it would be nice to eliminate it.
However, I'd like to see the Jakarta Platform specification updated to include
some aspects of the Managed Beans specification, such as a brief description of what they are, clarify that they are provided by the CDI specification, and how they relate to other specifications (i.e., how they are different from “application components”).
The Platform Specification already contains some information about “managed beans”, but they are referred to in different terms : “managed beans”, “ManagedBeans”, “JSF ManagedBeans”, and “CDI-stye managed beans”.
I think this is confusing, which is unfortunate, as one of the goals of the ManagedBeans specification was to avoid confusion by defining a common managed bean component model.
Really, the success of CDI solved the problems that the ManagedBeans specification was intended to address.
Other specifications deprecated their own “managed beans” in deference to CDI managed beans and CDI has become the common managed bean model for Jakarta EE.
Now is the time to update the Jakarta EE Platform specification to eliminate those old models (jakarta.annotation.ManagedBean and jakarta.faces.bean.ManagedBean) and indicate that CDI provides “managed beans” for the Jakarta EE Platform.
Looking back at the history of ManagedBeans, I think it was a mistake to describe EJB as a “managed bean”.
Sure, EJB is a “managed object” and has “bean” in the name, but what is more important from a Jakarta EE Platform perspective is that an EJB is an “application component”.
The Jakarta Platform specification defines 4 types of application components, (1) app clients, (2) applets, (3) servlets (web components), and (4) EJB.
A “managed bean” is not an “application component”, so it would be good for the Jakarta Platform specification to provide a better description of “managed beans”, including how they are different from “application components”, and how they may be used
by any application component (and inherit the context of the application component that uses them).
Perhaps most of that is already in the CDI specification, but some high-level information would be good in the platform spec.
All of injection (i.e., @Resoruce, @EJB, etc.) sections in the platform specification could also be updated to indicate that injection of those resources was applicable to both “application components” and “managed beans”.
Tracy Burroughs
(tkb@xxxxxxxxxx)
WebSphere Application Server Development
IBM Rochester, Dept AAW, Bldg H315/050-2
2800 37th Street NW, Rochester MN 55901-4441
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Jan Westerkamp
Sent: Friday, June 3, 2022 7:26 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Why haven't we removed Managed Beans?
+1 for removal As Arjan mentioned in another thread, this is obsolete and from the time, where CDI is intended to be more like a platform than a CDI Lite core spec.
When this Idea might come up again in the future, then with a dependency to
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
As Arjan mentioned in another thread, this is obsolete and from the time, where CDI is intended to be more like a platform than a CDI Lite core spec.
When this Idea might come up again in the future, then with a dependency to CDI instead from it.
When we can do it for the Jakarta EE 10 release, than it reduces complexity in all the profiles.
In a new CDI Service Release there is also a chance to remove the test dependency to org.testng:testng or at least update it to a newer version (current version: 7.6.0, or last major 6 version, in a case of
issues with 7: 6.14.3).
I think these test dependencies should not belong to an Interface only package, except for very good reasons - otherwise the tests should be part of the TCK or i.e. when testing generated stuff be part of an non-runtime utility.
+1. It’s definitely just a vestige of the distant past.
So Arjan pointed out there is a relationship between dependency injection and managed beans via a brief mention in the spec. Managed beans really have no purpose with CDI, so why don't we just deprecated and
drop it?
I'd be in favor of dropping Managed Beans.
For those who don't have the context, all of this at one point was in JSR-299 CDI (Web Beans at the time). Disagreements resulted in a JSR-330 Dependency Injection to offer dependency injection without the
icky EE stuff and later Managed Beans in hopes of offering one true generic component model. The details in Managed Beans were intentionally thin and the spec considered somewhat a placeholder for future work. Both JSR 330 and Managed Beans were never again
developed.
We've corrected part of this in Jakarta by having the Dependency Injection spec once again under the control of the CDI project. We should likely just remove Managed Beans. As DI and CDI came out in the
same Java EE versions as Managed Beans and Managed Beans was intentionally thin so very hard to understand, I'm not aware of anyone who has actually used it.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
