Some people have wondered why CDI requires an explicit @Named annotation before a bean can be accessed using EL? Why not just give all beans names by default?

Well, the reason is that EL has a single flat namespace. There's no notion of qualified names in EL. Experience in the JSF community is that avoiding duplicate names is harder than it looks, especially when the application includes multiple modules maintained by different teams. Remember that not all CDI beans are intended to form part of the user interface layer. A Java EE 6 application might include modules defining an independent business layer, whose beans should always be accessed via typesafe dependency injection instead of non-typesafe EL names. Beans in these modules should not have EL names, in order to avoid polluting the namespace of the UI layer.

Still, the combination @Named @RequestScoped is going to be super-common in JSF applications. So CDI includes a built-in stereotype that encapsulates these defaults. The @Model stereotype refers to the M role in the MVC pattern. We recommend that all JSF user-interface-oriented beans be annotated @Model to both save a little typing (one annotation instead of two), and, more importantly, to make clear their architectural role in the system.

Indeed, even when you have a UI model bean that's not @RequestScoped, I recommend annotating it @ConversationScoped @Model rather than @Named @ConversationScoped. The two options have the same functional effect, but the first combination communicates more information to someone reading your code later, and makes it easy to quickly search for all UI model beans.

(Of course, if, for whatever reason, you don't like @Model, you can always define your own stereotype to fulfil a similar purpose. The CDI container doesn't treat @Model in any special way.)

In case you missed it, Jay and Dan published an article about Ajax and JSF2 on DZone.

Andy Gibson has written a nice tutorial to help you get started with JSF 2 and CDI using Netbeans and Glassfish. It's great to see that both Netbeans and Intellij 9 already have excellent support for Java EE 6.

A developer new to Java EE posted in the Weld forum asking for advice on getting started learning EE 6. I've decided to promote part of my response in the forum to the blog.

So, what should I start learning. Java EE 5 and Seam? Java EE 6 and Weld? Is there any learning material about 6 and Weld right now?

Unless you plan on putting your system into production inside the next 2-3 months, you should start learning CDI and Weld. CDI defines the basic infrastructure you'll use to get the various kinds of Java EE components working together (and much more).

You also need to decide what web framework to use. This is the hard bit for most people.

• You could use plain servlets and JSP, which in EE 6 both include out-of-the-box CDI integration. However, most people prefer to use something with more features. But honestly, if you're new to enterprise Java, it's not a bad place to start. The latest servlet spec lets you use annotations, which is a big step forward in usability.
• JSF2 is included as part of the platform, and is integrated with CDI out of the box. Many people find JSF difficult to learn. We believe that for some kinds of applications, it pays off in the end. Unfortunately, most of the books and articles about JSF make it appear much more complex than it actually is. In particular, the specification is horribly written and not worth reading (so I won't link to it). Take a look at the Weld examples to get a taste of what JSF2 is really like.
• An option we recommend is Wicket. Wicket is an alternative to JSF that is easier to learn. Weld comes with Wicket integration.
• There are many other possibilities including about a thousand frameworks which are basically alternatives to the servlet API. Struts2 and Stripes seem like popular options. I don't find any of these kinds of frameworks very interesting or sexy, but they're usually easy to learn. It should be very relatively easy to integrate any of them with Weld.
• A final option worth mentioning is GWT. GWT is an entirely different beast, with its own Java to JavaScript compiler. It's great for certain kind of application. We should have GWT integration for Weld available very soon.

My personal view is that you should start out by looking at either JSF and/or Wicket, unless you're truly a beginner at this, in which case start with writing some plain servlets. If these options don't suit your needs, cast a wider net.

You'll also need a persistence solution. For most people writing EE 6 applications that means JPA2. There are at least three excellent implementations of this specification to choose from, including ours. You'll probably want to use JPA2 together with Bean Validation.

Once you've got a handle on CDI, JPA2, and whatever web framework you decide to use, take a look at EJB 3.1, and the more advanced functionality it offers for integrating with data stores and messaging, and managing asynchronicity. Unfortunately, the EJB spec itself is quite hard to read, so you should probably try to find a good tutorial. Be careful, there is still a lot of information about EJB 2 out there on the web. EJB 3.1 is a quite different beast.

In case you're like me, and you missed this when it was first published, check out Andy Schwartz's summary of what's new in JSF2. (Andy's one of the good guys on the JSF EG.) It's fun to compare the final product to my wishlist from back in '07. Oh, what innocent, carefree days...

Side note: is that really meant to be Andy Schwartz's blog rather than Andy Schwartz' blog?! How do you say that, Schwartsez?