DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Slimming Down Your CDI Memory Footprint
  • Upgrade Guide To Spring Boot 3.0 for Spring Data JPA and Querydsl
  • Spring, IoC Containers, and Static Code: Design Principles
  • Beans Custom Validation Constraints

Trending

  • Top Mistakes Made by Product Owners in Agile Projects
  • Best Plugins For JetBrains IDEs
  • Architecting a Completely Private VPC Network and Automating the Deployment
  • Anomaly Detection: Leveraging Rule Engines to Minimize False Alarms
  1. DZone
  2. Coding
  3. Frameworks
  4. You should not have any other @ManagedBean beside @Named.

You should not have any other @ManagedBean beside @Named.

Markus Eisele user avatar by
Markus Eisele
·
May. 05, 11 · Interview
Like (0)
Save
Tweet
Share
6.24K Views

Join the DZone community and get the full member experience.

Join For Free

Provocative title, I know. But this is what my mind came up with, reading about @EdBurns latest survey where the JSF EG asks the community: "Should we deprecate Managed Beans in #JSF 2.2?". Seeing the first intermediate direction from today, it's the majority of the voters (roughly 80%), which vote for removing/deprecating them.
Great indication not only for the JSF EG but also for the whole EE 7 EG. Why?

What's all this about?
It's about the Faces Managed Beans. It defines a couple of Annotations for automatically registering classes with the runtime as a managed bean class within specific scopes. Classes must be scanned for the presence of this annotation at application startup, before any requests have been serviced. As you can see from the comments, it has been planned to extract the specification for managed beans from JSF and place it into its own specification since the 2.0 (Java EE 6). If you compare the features with the ones provided by Contexts and Dependency Injection (CDI). CDI defines a set of contextual services, provided by Java EE containers, that make it easy for developers to use enterprise beans along with JavaServer Faces technology in web applications. Designed for use with stateful objects, CDI also has many broader uses, allowing developers a great deal of flexibility to integrate different kinds of components in a loosely coupled but type-safe way. If you compare the scopes in javax.enterprise.context.* and javax.faces.bean.* (Weld API Docs, DI API) you see some common names. And that basically is the problem here. You can achieve mostly the same using the javax.faces.bean.ManagedBean or any javax.inject.Named with a CDI Context. This multiple solutions space not only covers JSF but also the javax.annotation.ManagedBean (API) and with it the complete platform. The ManagedBean annotation marks a POJO (Plain Old Java Object) as a ManagedBean. A javax.annotation.ManagedBean supports a small set of basic services such as resource injection, lifecycle callbacks and interceptors. It seems as if this was intended to be a first draft of the new container objects which don't have to implement interfaces or conform to any container requirements except the fact, that they have a special annotation with them.

What does it mean to remove the Faces Managed Beans?
Depending on you view onto the platform it could either be a first step into consolidation of the different ManagedBean approaches with Java EE or even a step to make JSF completely dependent on the Java EE Web Profile. If the Faces Managed Beans feature is dropped, you need any kind of Managed Bean service to the core JSF functionality. A standalone appserver which does not contain one of the mechanisms JSF will depend on (CDI/DI or EE ManagedBeans) will not be able to run it anymore. So, you decide weather or not JSF could be used without a EE profile or not.

What do the experts say?
I can only speak for myself here, rate for yourself if you still need the answer from an expert :) I personally voted for removing the Faces Managed Beans. They cause confusion with developers. Removing them force the EE 7 EG to think about a general approach for other specs being in a comparable situation (present and future). The drawback is, you will probably lose the ability to run on very lightweight Java appserver which do not conform to one of the defined profiles and can't provide DI/CDI features.
Further on, there are still complaints about the quality and performance of WELD being the RI for CDI. So, in the end, I believe a couple of actions have to be taken to make the removal of the Faces Managed Beans a success story. But it will be worth it: Looking at the complete Java EE 7 platform!

Cast your vote here! Help shape Java EE 7 and beyond!

I would love to read about your thoughts! Please take a minute to express your ideas and rating on that in the comments! 

From http://blog.eisele.net/2011/04/you-should-not-have-any-other.html

Java EE Bean (software) Spring Framework

Opinions expressed by DZone contributors are their own.

Related

  • Slimming Down Your CDI Memory Footprint
  • Upgrade Guide To Spring Boot 3.0 for Spring Data JPA and Querydsl
  • Spring, IoC Containers, and Static Code: Design Principles
  • Beans Custom Validation Constraints

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: