Skip to main content
[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?
Hi,

With EE 6 there was some formal introduction of a deprecated and then pruned/optional process. Seems fine to me and consistent to mark it as deprecated for inclusion in the platform and web profile.

Kind regards,
Arjan Tijms


On Thu, Jun 9, 2022 at 5:47 PM Scott Stark <starksm64@xxxxxxxxx> wrote:
It is the approach taken in previous deprecation/removals. For example, Jakarta XML RPC is marked as optional in EE 8 (don't know where it was deprecated), removed in EE 9 with just two references to it being a removed technology, and there was no update to the 1.1 spec to indicate it was deprecated:



On Jun 9, 2022 at 10:27:47 AM, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
Is this the process we used for deprecating specifications in the past? If there is no process, we might need to set up one for future reference.
Thanks,
Emily

On Thu, Jun 9, 2022 at 12:23 AM Scott Stark <starksm64@xxxxxxxxx> wrote:
I don't think it makes sense to update a spec to say it is deprecated. It is being deprecated for inclusion in the platform and web profile, and for that I have the following PR:


We do need a service release of the commons annotations api that merges this change:

On Jun 8, 2022 at 5:23:23 PM, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
Scott,
Are you going to do a service release for Managed Bean spec to announce the deprecation?
Thanks
Emily

On Tue, Jun 7, 2022 at 5:26 AM Scott Stark <starksm64@xxxxxxxxx> wrote:
I think so. We can discuss tomorrow.

On Jun 6, 2022 at 5:54:00 PM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

Would it still be doable to add a deprecation or intend to prune notice in that platform spec about this for EE 10?

Kind regards,
Arjan Tijms

On Mon, Jun 6, 2022 at 11:33 PM Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
+1 on removing managed beans jakarta.annotation.ManagedBean and jakarta.faces.bean.ManagedBean! I have seen a lot of confusion from customers. They had no idea which managed bean to use. Even worse, this also created confusion with CDI beans.

I suggest removing all occurrences of managed beans. If they need to be beans, they should be updated to CDI beans. Let's not use managed beans but settle on CDI beans once for all.

When we drop the managed bean spec, we need to update CDI spec to remove the section (documenting the relationship with the managed bean spec) .
Thanks
Emily

On Fri, Jun 3, 2022 at 9:07 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:


On Fri, Jun 3, 2022 at 9:59 PM Tracy Burroughs <tkb@xxxxxxxxxx> wrote:

+1 for removal

would also like to see jakarta.faces.bean.ManagedBean removed as well. 


jakarta.faces.bean.ManagedBean has been removed in Jakarta EE 10 / Faces 4.0 ;)

Kind regards,
Arjan Tijms

 

+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

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

+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.

 

Am 03.06.22 um 02:12 schrieb reza_rahman@xxxxxxxxx:

+1. It’s definitely just a vestige of the distant past.

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of David Blevins <dblevins@xxxxxxxxxxxxx>
Sent: Thursday, June 2, 2022 8:04 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Why haven't we removed Managed Beans?

 

On Jun 2, 2022, at 4:37 PM, Scott Stark <starksm64@xxxxxxxxx> wrote:

 

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

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


--
Thanks
Emily

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


--
Thanks
Emily

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


--
Thanks
Emily

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top