myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pieter Martin <>
Subject Re: Conversations
Date Fri, 01 Jul 2011 14:07:17 GMT

Currently I have gotten the following to work, using only request scoped 
db instance and backing beans.

public class FacesListener {
     NakedGraph db;
     Logger logger;

     public void beforeFacesRequest(@Observes @BeforeFacesRequest 
FacesContext ctx) {
         logger.fine("beforeFacesRequest, setting db and starting 

     public void afterFacesRequest(@Observes @AfterFacesRequest 
FacesContext ctx) {
         logger.fine("afterFacesRequest, stopping transaction and 
removing db");


GraphDb is a threadvar.

I am hoping to do something similar but for a ConversationScoped db 
instance and backing beans. However the conversation is not active 
during beforeFacesRequest.

The idea is to have a conversation scoped producer for db instance. With 
a corresponding @Disposal method to ensure that the db instance is 
closed properly. For every request made from jsf before jsf touches any 
beans I need to set the db instance on the threadvar and start a 

The above code does not work as the conversation is not yet active 
during beforeFacesRequest.

When I go to a particular page, with a conversation scoped backing bean, 
the backing bean will make entities available, loaded from the 
conversation scoped db instance to view/edit on the page. Then on 
updating a particular entity (backingBean.update) , seeing as jsf 
directly access the entity and sets the fields the db instance needs to 
have been set on a threadvar before jsf accesses the entity.

I am looking for a listener of sorts to set the threadvar and start the 
transaction before jsf touches any beans but after the conversation is 

Hope it makes some sense.

On 01/07/2011 09:15, Gerhard Petracek wrote:
> hi pieter,
> please provide a bit more details. esp. the first phase of the jsf
> request lifecycle which has to access this instance and how you would
> like to access it.
> codi tries to restore the window-id as early as possible. the first
> attempt is before the restore-view phase. if it isn't possible there,
> codi restores it after the restore-view phase.
> conversation scoped beans can be accessed as soon as there is a window-id.
> regards,
> gerhard
> 2011/6/30, Pieter Martin<>:
>> Hi,
>> I have the following requirement and wondering how to implement it with
>> codi.
>> We want to use conversations and have a database instance that is
>> conversation scoped. However for every request that we need to put the
>> conversation scoped database instance in a threadvar where domain
>> entities can access it later. We are using a graph db and the domain
>> entities uses the db instance to add vertexes and edges.
>> For request scoped use cases it is easy to set the threadvar when
>> observing the @BeforeFacesRequest event and to clear the threadvar on
>> the @AfterFacesRequest.
>> However this does not work for conversation scoped use cases as the
>> conversation context is not yet active.
>> Is there a suggested way for me to achieve this?
>> Thanks
>> Pieter

View raw message