There is a lot of buzz (not only recently) around some extra scope, that is shorter than a session and longer than a request. Such a scope is a very good scope to implement business processes or some wizard (==> step x of n). Lots of frameworks call this “conversation”, so does Orchestra or Seam. In Trinidad there is a “pageFlowScope” for this…

One of the goals of JSF 2.0 is to “standardization of the many different Dialog/Conversation/Scope/Flash ideas currently in use”. On the other hand there is the WebBeans standard, that tries to contribute some ideas of the Seam framework to the Java EE community (and some DI ideas from Google Guice).

Seam as you know has also this extra scope… and if both JSF and WebBeans would address this issue, there would be two beasts for the same story.

So, one could think that JSF should just relay on WebBeans for that kind of functionality, but that would cause a serious amount of headaches when it comes to the JSF 2.0 adoption… Similar like it was, when the JSF 1.2 hit the road (it introduced the dependency to JSP 2.1…). So if JSF 2.0 has a mandatory dependency to WebBeans it could make things harder than needed. Same would be true if other web frameworks, like wicket, want to use this. Yes, it is possible…

But again, it is huge dependency for a common feature…

So, why not adding this scope could to a more generic layer, like the servlet layer ? That would be very common for almost all (java) web frameworks How could it be standardized at Servlet level? Adding URL parameters (like jsessionid), but that wouldn’t be URL copy-paste proof when opening a tab… or cookies? Those can disabled by the browser…

Why not just adding a raw API for “conversations” to the Servlet layer? No implementation at all. JSF (and others) could (not have to) provide an implementation of this… That would mean all these framework kinda use the same (common) API, but everybody solves the issue on its own.
(sure, when this part of Servlet 3.0 there is still an issue with the adoption, but a Servlet 3.0 adoption isn’t an elephant like WebBeans)

Funny enough, the Orchestra library already has an abstract FrameworkAdapter, that provides access to all the data necessary for Orchestra to work while isolating Orchestra from the actual UI presentation framework being used.

I think it would be good if a similar thing is provided by the Servlet layer. JSF (or other web frameworks) could just offer the implementation, if they want…

I really hope conversations somehow make it into the java web land….