[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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 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