From the Tapestry doc I seem to understand that a field annotated with @SessionAttribute and a field annotated with @SessionState work in the same way, except that @SessionAttribute stores the value by name (and the name can be specified), which means that different instances of the same class can be stored, while @SessionState stores the value by type so storing different instances of the same class will not work, the new instance will always overwrite the old one (even if the two are different fields with different name and from different classes).
So it seems that @SessionState doesn't offer any advantage over @SessionAttribute, only limitations, but I'm probably missing something. I'm not able to figure out any case where using @SessionState could be more advisable than @SessionAttribute for any reason.
Are there such cases ?
@SessionAttribute is largely intended for some interop cases, where some other, non-Tapestry code (another servlet) is expecting the data to be stored using an explicitly specified name.
@SessionState's advantage is that the name is automatically determined from the type ... one less thing to care about, and more amenable to refactoring.