• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 563
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marco Ehrentreich
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic