One of the features I am most pleased to see in Seam 2.0.1 is Natural Conversations. Why?

Easy redirect to existing conversations

It can be useful to redirect to an existing conversation if the user requests the same operation twice.

Take this example:

You are on ebay, half way through paying for an item you just won as a Christmas present for your parents. Lets say you're sending it straight to them - you enter your payment details but you can't remember their address. You accidentally reuse the same browser window finding out their address. Now you need to return to the payment for the item.

With a natural conversation its really easy to have the user rejoin the existing conversation, and pick up where they left off - just have them to rejoin the payForItem conversation with the itemId as the conversation id.

User friendly URLs

I've always been a strong believer in the use of user friendly, descriptive, URLs. For some applications this is of less import, of course - the largest (pre Seam) application I wrote was really bad at this as it used frames ;-) . For me this consists of:

• a navigable hierarchy - I can navigate by editing the url
• a meaningful URL (like this Wiki uses -- so don't identify things by random ids)

The first of these is certainly possible in Seam with the use of URLRewrite (I'm also looking forward to seeing stronger integration between URLRewrite and Seam's pages.xml), but the second was harder until now.

Now, with natural conversations, when you are building your hotel booking system (or, of course, whatever your app is) you can generate a URL like http://seam-hotels/book.seam?hotel=BestWesternAntwerpen (of course, whatever parameter hotel maps to on your domain model must be unique) and with URLRewrite easily transfor this to http://seam-hotels/book/BestWesternAntwerpen.

Much better!

Deprecates explicit synthetic conversation ids

I really didn't like the use of explicit synthetic conversation id - they just feel really ugly to me. You know that gut feeling you get about some things? Explicit synthetic conversaton ids are like that for me.

This is available in the recently released 2.0.1.CR1.

I hope this inspires you to go out and think about how you can incorporate natural conversations into your application.

Well, help is on hand. Jacob Orshalick wrote an excellent article on nested conversations which he seems to be making into bit of series with this latest blog posting on conversation timeouts.

Enjoy!

A quick update for those who like living on the edge ;-)

Firstly, I've published a snapshot of Embedded JBoss beta3 - this is a pretty major update to Embedded JBoss (and its components like EJB3, Hibernate etc.) and pretty close to the beta3 release - so it would be great to get some feedback. It's looking good (but there is a known issue with JMS).

If you want to give it a go:

• Tomcat: Follow these instructions to install into a /fresh/ copy of Tomcat.
• SeamTest: Replace your current bootstrap directory and lib/test directory

Secondly, if you've made the move to Java 6 you need a couple of tweaks to Embedded JBoss for the beta3 snapshot:

1. Start java with -Dsun.lang.ClassLoader.allowArraySyntax=true
2. Java 6 SE includes JAXB 2.0, but Embedded JBoss needs JAXB 2.1. The easiest way to do this is to put the jaxb-api.jar (for JAXB 2.1) into the endorsed library directory, then start java with -Djava.endorsed.dirs=/path/to/endorsed/directoy

Your testng launcher would look something like this:

<testng outputdir="/path/to/test/report/directory">
   <jvmarg line="-Djava.endorsed.dirs=/path/to/endorsed/directory" />
   <jvmarg line="-Dsun.lang.ClassLoader.allowArraySyntax=true" />
   <classpath refid="test.classpath" />
   <xmlfileset dir="/path/to/src/directory" includes="**/testng.xml" />
</testng>

I've just installed Fedora 8 on my ThinkPad X60, and as it comes with packages for Iced Tea (Red Hat's version of OpenJDK), I thought I would take the Seam Booking Example out for a spin.

Well, it was a very pleasant experience - I booted the Fedora KDE LiveCD, and ran the Fedora installer from the desktop which took about 20 minutes. Once I had rebooted, I used the package manager to the /Java Development/ set of packages (which gave me Iced Tea and ant). I then downloaded and unzipped JBoss AS 4.2.2.GA and Seam 2.0.0.GA, deployed the booking example, started JBoss AS, and booked myself a suite!

I did notice that the application seemed more faster than normal, so I took a look at my favourite completely subjective performance measure -- how long it takes JBoss AS to start with just the booking example deployed -- and it seemed good at around 20s.

This piqued my interest, so I did a highly unscientific test and installed the Sun JDK 1.5.0_14 and the Sun JDK 1.6.0_03, and (using Seam and the example compiled by JDK 1.5) took a look at how long the server takes to start.

I found that using JDK 5 to boot the server it took 32s, using JDK 6 it took 25s and using Iced Tea (JDK 7) 21s -- definitely going in the right directions! I then compiled Seam and the example using Iced Tea, and (running JBoss AS using Iced Tea) got a startup time around 19-20s.

Of course, this no match for a real performance test, but I found it interesting.

I'm using <s:convertEntity /> and when I submit the form I get an error message on the page /Value is not a valid option/ — what am I doing wrong?

This commonly asked question on the Seam forum refuses to go away — so lets run through the problem, look at the workarounds and what changes would be needed to JSF to make it go away.

The Background

JSF allows you to specify a converter for any editable value; the converter converts /from/ an Object /to/ a String when rendering the page, and /from/ a String /to/ an Object when submitting a form. JSF comes with some built in converters (e.g. for Date, enums...) or allows you to create a custom converter.

Inside your custom converter you implement getAsString, returning a String, which, when passed to getAsObject on submitting the form, you use to get hold of the Object and return it.

Seam provides <s:convertEntity />, a generic converter which does the job of converting any JPA entity (mapped with annotations or XML, with a simple or composite key). It takes the primary key of the entity, stores it, returns a reference to the location in the key store; when the page is submitted, the key is fetched from the store and used to load the entity.

The Problem

The JSF 1.2 Specification (sections 4.1.15.3 and 4.1.16.3) specify that

...must provide a specialized validate() method which ensures that any decoded value is a valid option (from the nested UISelectItem and UISelectItems children).

In other words, the submitted item must be in the list displayed on the page. As the entity converter loads the selected object from the persistence context when the page is submitted, /the submitted object is not in the displayed list/.

The Workarounds

1. Display the list and submit the form inside the same long running conversation (so that the persistence context returns the same object both times). This makes caching the list of selectable items hard.
2. Overriding equals() on the entity (which isn't a a great idea).

The Solution

For JSF 2 this validation should be optional/overrideable (as it is everywhere else in JSF). In this case the converter is doing all necessary validation.