Markus is a Developer Advocate at Red Hat and focuses on JBoss Middleware. He is working with Java EE servers from different vendors since more than 14 years and talks about his favorite topics around Java EE on conferences all over the world. He has been a principle consultant and worked with different customers on all kinds of Java EE related applications and solutions. Beside that he has always been a prolific blogger, writer and tech editor for different Java EE related books. He is the Java Community leader of the German DOAG e.V. and it's representative on the iJUG e.V. As a Java Champion and former ACE Director he is well known in the community. Markus is a DZone MVB and is not an employee of DZone and has posted 189 posts at DZone. You can read more from them at their website. View Full User Profile

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

05.04.2011
| 4599 views |
  • submit to reddit

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

Published at DZone with permission of Markus Eisele, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Fab Mars replied on Thu, 2011/05/05 - 3:06pm

There was no time to consolidate all before EE6 was finalized so we ended up in a situation where @ManagedBean @javax.faces.bean.RequestScoped was similar to @Named @javax.enterprise context.RequestScoped

Working in the EE ecosystem without using CDI sounds like heresy to me now. Would you use a stagecoach to move into NYC? No? Same thing here.

By the way Weld performance has greatly improved with release 1.1(.1). And this is a false problem unless you run your app server on a wheelbarrow-server. I'm sure we will hear about that urban legend for years (same as the things supposedly broken in JSF, which were actually fixed in 1.1 and 1.2, four or five years ago...). Maybe people should:
- actually test Weld performance themselves
- move to Glassfish 3.1
- write code that's freed from useless patterns multiplying classes and interfaces.

Anyway managed beans can still be declared within faces-config.xml. It's sometimes even necessary in some inheritance/multiple declarations cases, so even though I didn't follow the JSF EG discussions, I doubt the xml config will disappear. Thus JSF can still be independant. But does it even make sense?

To me it's crystal clear that @ManagedBean (and the javax.faces scope annotation) should be deprecated to avoid confusion and have a more coherent platform as a whole.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.