Dan Allen

Also, you can go straight to the source and read the EL part of the latest JSP specification (2.2), which covers these new features.

http://jcp.org/aboutJava/communityprocess/mrel/jsr245/index.html

Weld provides an uberjar (single JAR) that provides everything you need to use CDI in a servlet container (such as Tomcat or Jetty). The best way to get started with CDI (whether in a servlet container or Java EE application server) is to start with the Maven 2 archetypes provided as part of the Weld project: http://seamframework.org/Documentation/WeldQuickstartForMavenUsers

Just to clarify, it isn't required that you deploy JSF 2 applications to a Java EE application server, but it is the recommended approach. Note that JSF 2 will run fine on a servlet container (Tomcat, Jetty), it just requires a couple more steps to setup. Cay puts it into perspective in his blog: http://weblogs.java.net/blog/cayhorstmann/archive/2009/12/29/jsf-20-and-tomcat

The decision to implement the conversation scope within JSF was deferred as it was decided that it would be more appropriate to implement the scope at a level in which it could be shared/accessed across the Java EE platform. Scopes which provide this level of visibility are defined in JSR-299: CDI. Therefore, the official conversation scope for JSF is indeed the conversation scope defined by JSR-299.

However, because of the order in which the specifications were finalized, JSF 2 wrapping up nearly 6 months before CDI, it was not possible for JSF 2 to provide UI components that would aid in managing the boundaries of the conversation scope like Seam provides. Now that CDI is officially part of the Java EE platform, you can expect that, moving forward, we can take steps in JSF to help support the conversation scope.

One consequence of the decision to move the conversation scope to CDI meant that it's necessary to use JSF 2 in conjunction with CDI. This turns out to be a good thing because the services that CDI provide (dependency injection, managed bean discovery/definition, events, etc) go way beyond the JSF managed bean facility and is well worth the commitment. I recommend this strategy strongly over trying to implement a conversation scope using the JSF 2 custom scopes.

There is an FAQ that gives the latest details about using Seam 2 with JSF 2 here: http://seamframework.org/Documentation/DoesSeamWorkWithJSF2

The topic about the future of Seam is better suited for the forums at seamframeork.org: http://sfwk.org/Community/SeamUsers

In support of Ed's statement, you will no longer look to Seam to provide a component model and dependency injection as that is now provided in the Java EE platform as part of CDI (JSR-299). What Seam will continue to provide is all of those enhancements, goodies and integrations that get layered on top of Java EE. But you are encouraged to get started today discovering what Java EE 6 provides for you out of the box. There is a lot in there.

These new components are exciting mainly because they were sorely missed in earlier versions of JSF. At last, they are available. The reason they were missed is because regular hyperlinks happen to be the most common way to link pages (the other way being a form submission). So the thing that you had to do the most often was kind of difficult. Your only option was to use <h: outputLink>. But that component has no concept of view IDs, so the target would have to be a URL that included the servlet mapping (*.faces or /faces/*).

The <h:link> and <h:button> are also compelling because they can manage the query string for you when combined with view parameters. If you've ever created a search form like bugzilla (see https://javaserverfaces-spec-public.dev.java.net/issues/), you would have had to itemize and propagate each individual request parameter that makes up the search anywhere you have links on the page. View parameters allow you to declare the request parameters on the target page (as view parameters) and those parameters will automatically be added to any links that target that view ID. So it turns out to be very convenient.

JCDI is the new acronym for JSR-299, formally Web Beans. Actually, Web Beans is now the name of the Reference Implementation, which turns out to work out quite well. http://seamframework.org/WebBeans

Seam isn't coupled to RichFaces at all. If you want to use Dojo, you have two options. First, you can use Seam Remoting, which is like DWR except the exchange format is XML. But what's even more attractive, and I highly encourage you to try, is Seam's JAX-RS (RESTeasy) integration. This allows you to setup a REST web service and return a format of choice (XML, HTML, plain text, JSON). In little to no time you can get a Seam backend service working for a Dojo frontend. Try it out!

Deprecated is sort of the wrong word for how outjection is being handled in Seam 3. It will be available in Seam "classic" mode, which Seam 3 will fully support. Developers will be encouraged to embrace JCDI's producer methods, which are like super charged factory methods. But the jury is still out from the community as whether producer methods will completely replace the need for outjection or not. We have to see what people like. If there is still a strong case for outjection, it will stay (just not in JSR-299/JCDI). Personally, I still find it extremely useful and don't really get confused by it.

It should also be noted that in SVN, seam-gen can create projects that are deployable to JBoss AS 4, JBoss AS 5, GlassFish V2, and GlassFish V3. That's just to demonstrate what is possible. With just a few extra tweaks to the build, the project could be deployed to other servers as well.

Understand that Seam is, was, and always will be about supplementing Java EE to give you features today that are being worked into the specs of tomorrow. So there is no reason why Seam shouldn't be able to run on any application server because it extends the platform the way it was designed. Now and again Seam developers have made mistakes that have messed up compatibility, both those were just bugs and got resolved by community feedback.

Exactly. If it were so easy to create projects, then the success rate of projects would be a lot higher. I do think it can be that easy to evaluate a framework though.

I think you are slightly missing the point about the purpose of seam-gen (I can't speak for other code generators). The main goal of seam-gen is to allow you to begin evaluating Seam with next to little overhead. To make the evaluation relevant and productive, it offers a code generator so that you can get some screens together and start hacking on them (and perhaps to show your boss you actually did something). We are still a ways off (I'm not ruling it out) from when code generation can replace custom development. For that reason, seam-gen doesn't try to build the perfect application.

With all of that said, if you are looking for better code to be generated, it's easy (if you understand FreeMarker and Hibernate Tools) to modify the templates and generate more of what you want. But please don't lose focus on the fact that seam-gen is there to produce a custom example that you can build on. Seam is about much more than just seam-gen.

The economy is tough and your company doesn't have money for you to travel, so you can't go to any conferences this year, right?

Wrong.

JBoss is getting its "Second Life" on by hosting a purely virtual conference on Feb 11 (it's not actually in Second Life, it's just streaming over the internet). Not only do you save money on airfare and hotel, you don't even have a conference fee to worry about. You just need to sign up, clear your schedule on Feb 11, and e-ttend! There's even going to be a virtual trade show!

The JBoss Virtual Experience 2009
Enter. Discover. Advance.
February 11, 8:30am - 6:00pm EST

A one-day event focused on enterprise-class, open source middleware. Attend comprehensive sessions and chat live with open source leaders, executives, key developers, customers, and strategic partners. Register for free here:

http://www-2.virtualevents365.com/jboss_experience

Pete Muir and I will be co-hosting a session on Seam and Web Beans titled "The future for Seam: Web Beans and beyond". We will address that burning question, how will Seam and Web Beans coexist and what is their relationship? For those of you who have not yet looked into Web Beans, this is your chance for a gentle introduction.

In other news, Web Beans is now "the spec formally known as Web Beans." Find out by reading this blog entry what it will be called when it becomes an official part of the Java EE 6 platform and the reason for the name change. Mark my word, this is a great move for the platform.

Awesome, I plan to spend some time reading the sections that deal with managing multiple instances. In the end, you really need to know about each approach because different circumstances call for different approaches. You never know what is going to come up.

JBoss sells subscriptions. That's the official answer. Of course, they are still working to educate the industry what that means exactly. Peter does a nice job of explaining the difference between the community and commercial bits. However, I want to provide some extra information to may make you feel a more comfortable with the whole situation.

Open source software means many things to many people. To JBoss, it's about empowering the users of the software to become part of the process and contribute their ideas, bug reports, patches, and guidance and to have the freedom to use the software for free. The community version is as strong as the community that is actively involved in developing it. Some projects have community members that are so passionate that you get answers and bug fixes very fast. Other projects may have a slower turnaround. Because it's community supported, you are at the whim of the community and their personal time. That goes for all open source projects.

If you need reliable dates, dedicated resources, and dependable progress, then what you are looking for a subscription. JBoss doesn't view people using the community version as freeloaders and the commercial customers as more respectable. The commercial customers are the business customers and the community members are contributors.