Managing conversations thru url patterns

[davisonri_k12]

In Seam 2 I could configure transaction boundaries via the pages.xml thru something like this

<begin-conversation join="true"/>

1. Is there something similar that I can do for SEAM3/Weld ? I want to be able to manage/start conversations when a page with a specific url pattern is accessed.

2. Also I have a single page with some ajax features within it and I dont have a long standing conversation since this is a standalone page (e.g may be a dashboard). When i make ajax requests from the page (that onlyre-renders a certain widget on the dashboard) does that ajax request result in a new conversation ? in other words is the ajax call considered to be an jsf request thus starting off another transient conversation. this is the behaviour I am seeing right now. Can someone please confirm that this should be the case?

I am a newbie to SEAM3 and CDI and so any help would be appreciated.

[lightguard]

Dave seenam wrote:

In Seam 2 I could configure transaction boundaries via the pages.xml thru something like this

<begin-conversation join="true"/>

1. Is there something similar that I can do for SEAM3/Weld ? I want to be able to manage/start conversations when a page with a specific url pattern is accessed.

IIRC the ViewConfiguration stuff in Seam Faces let you do this on an enum, but we don't have anything to configure it via XML or the like.

2. Also I have a single page with some ajax features within it and I dont have a long standing conversation since this is a standalone page (e.g may be a dashboard). When i make ajax requests from the page (that onlyre-renders a certain widget on the dashboard) does that ajax request result in a new conversation ? in other words is the ajax call considered to be an jsf request thus starting off another transient conversation. this is the behaviour I am seeing right now. Can someone please confirm that this should be the case?

You are correct.

[davisonri_k12]

In what JSF phase does a transient CDI conversation get promoted to a long standing conversation. I am assuming that this happens in the invoke application phase since this is this is where the Conversation.begin() method can be called.

I am looking to implement a mechanism to start start conversations in the JSP phase listener. By configuring certain view ids as the starting point of a conversation (build on top of the ViewConfig in seam 3). So in the JSF listener i want to be able to check to see if a conversation needs to be started if current view id is the same as the configured view id. Kind of similar to conversation-begin tags within pages.xml - a feature that does not exist with seam 3.

[lightguard]

In CDI 1.1 I doubt you'd be able to do this in a portable fashion just because of how conversations were specified and implemented. CDI 1.1 should allow you to do this easily. For now, take a look at how things were done in the Seam Conversation module.

[davisonri_k12]

Strike that. Looks like it should happen before the render response phase. would that be correct ? atleast looks like how that was handed in SEAM 2

[davisonri_k12]

ok i am not sure i understand. in CDI 1.1 i should be able to do this ?

[lightguard]

In CDI 1.1 (EE7) the conversation is not directly tied to JSF as it is in CDI 1.0.

[davisonri_k12]

Jason Porter wrote:

In CDI 1.1 I doubt you'd be able to do this in a portable fashion just because of how conversations were specified and implemented. CDI 1.1 should allow you to do this easily. For now, take a look at how things were done in the Seam Conversation module.

I dont see a converstion module in seam 3.

also if such a conversation management solutions built on top of the ViewConfig is not ok, then am i to believe that the only acceptable way to ever start conversations is explicity calling conversation.begin() wherever i expect a conversation to exist. which could be end being in several places.

[lightguard]

https://github.com/seam/conversation

I'm not sure when it will be ended if using the ViewConfig, it's been a while

[davisonri_k12]

Thanks. I am going to take a look at this.  but in the meanwhile I dont see any issues if I were to implement something like this

@LoggedIn

@FacesRedirect

@ViewPattern("/myApp/customer/*")

@AccessDeniedView("/public/login.xhtml")

@LoginView("/public/login.xhtml")

@BeginConversation

CUSTOMER_PAGES

And this is would basically take care of there being an conversation for any view id within /customer/*. Since there could be, in my case, several different ways to view any view within that url pattern. The @BeginConversation would be read during the @before RenderResponse phase in a phaseListener and start a conversation if there already did'nt exist one. Thoughts ?

[lightguard]

No, that should be fine. @EndConversation though, I'm not sure when that conversation would be ended.

[davisonri_k12]

we dont explicitly, in our case, end conversations. since the user can navigate to other apps and never come back. We do that by keeping a short time outs for conversations.