File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSF and the fly likes [JSF 2]  @javax.faces.bean.ManagedBean or @javax.inject.Named ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "[JSF 2]  @javax.faces.bean.ManagedBean or @javax.inject.Named ?" Watch "[JSF 2]  @javax.faces.bean.ManagedBean or @javax.inject.Named ?" New topic
Author

[JSF 2] @javax.faces.bean.ManagedBean or @javax.inject.Named ?

Celinio Fernandes
Ranch Hand

Joined: Jun 28, 2003
Posts: 547

Hi,

I have a question about the way we now declare managed beans in JSF 2.
Which annotation should we use at the class level :

@javax.faces.bean.ManagedBean or @javax.inject.Named ?

With CDI (JSR 299) now available in Java EE 6, I am not sure which one to use when creating managed beans for JSF.

What do you recommend and why ?

Thanks for your feedback.


SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCBCD 5
Visit my blog
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

Hi Celinio,

from what I read the @Named annotation should now be preferred. Unfortunately I'm still looking for a detailed explanation why! To my knowledge (from what I read) a main difference is that @ManagedBean allows injection of resources like EJBs or a PersistenceContext for example.

But I'd still like to hear the answer of someone who knows for sure!

Marco
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16160
    
  21

I believe that @ManagedBean permits you to specify the bean's scope.

That said, I'm not a big fan of annotating everything in sight. One of the main intents of the newer framework such as EJB3 and JSF was to make stuff more reusable by employing POJOs, and when you go annotation crazy, you're reverting to the old, less flexible approach. Although at least with annotations, the extra magic only applies when a suitable annotation processor is in use, and many annotations are overridable via an XML file.

The other reason to be judicious with annotations is that if you start doing a mix-and-match code reuse, you may end up with half your specs in the beans and half in a config file, and the end result is that there's no "big picture" available of what's what and how things interconnect. It devolves into a Treasure Hunt. Which seems to be my phrase of them month. Treasure Hunts destroy productivity.


Customer surveys are for companies who didn't pay proper attention to begin with.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

I believe that @ManagedBean permits you to specify the bean's scope.

I believe you can specify scope annotations for @Named and @ManageBean, but here again there are JSF specific scope annotations and CDI specific similar ones. I just don't understand what each group of annotations is for. Unfortunately you often can't see in examples on the internet which annotation was used withouth seeing the import statements.
Treasure Hunts destroy productivity.

I absolutely agree!
when you go annotation crazy, you're reverting to the old, less flexible approach

I know what you mean but I think verbose XML files won't make the problem much better. It would be nice to have a compiler flag to switch on or off annotations so that you could use annotated classes as pure POJOs when needed and turn on annotation support when you want the extra magic and you have the required libraries at hand. I personally would choose to live with annotations as long as it doesn't make trouble and maybe pull them out into XML when really needed. Or only for the classes you want to use as-is outside the platform.

That said I still see value to resort to XML-only configuration when you need the said "big picture", like JSF page navigation rules for example. Of course it would be much easier to make heavier use of XML with really good IDE support but without it XML is just too verbose in my opinion.

Marco
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16160
    
  21

Annotations can be applied at compile time or at run time. I think all the JSF and injection-related annotations are runtime only, though I'm not certain.

A runtime annotation requires a runtime subsystem to scan and act on those annotations. For example, I have to add an instrumentation handler to Tomcat in order to make my Spring JPA stuff work, since Tomcat doesn't have built-in EJB3 annotation handling the way that full Java EE servers do.

You can write compile-time scanners that can document the Big Picture and even integrate them into IDEs and documentation tools. In fact, XDoclet did that sort of stuff before annotations replaced it. The only problem there is that someone actually has to develop these tools, whereas a static declaration file has it all laid out for the world to see without special assistance.

The standard philosophy regarding annotations/XML is that the XML file will override the annotation, allowing altered behavior/properties without actually requiring editing and/or recompiling of the original annotated class. So you can do a "management by exception" if you like.

As far as large cumbersome XML files go, you can pretty much take it as a given that if the XML file is large, then it's because there's a large number of items being controlled (unless it's doing some really fine-grained control!). So you get your choice. Look at lots and lots of files or one big file.

Actually, there's often a third alternative. Both JSF and Spring allow you to split into multiple config files, if that helps you organize a large project better.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

What I meant with "switching on/off annotations" was that there should be a compiler flag to reuse annotated source code even if you don't have the libraries which define the annotations, so I meant compile time reuse to make annotations invisible to the compiler. But of course this would be a lot more difficult in practice as you probably wouldn't want to turn on/off all annotations.

Anyway the advantage I see in using annotations is that many annotations to me make more sense when they are placed inside the context where they belong to, i.e. usually the class. If I know the class I have to work with, I know where I can find class-specific annotations even though the annotations are obviously spread around lots of different source files. But as I previously wrote there are other use cases where I'd see the benefit to have exactly one XML file.

Marco
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: [JSF 2] @javax.faces.bean.ManagedBean or @javax.inject.Named ?