hi pieter, you can try to patch codi with [1] (attention: it wouldn't work in combination with view-access scoped beans). if it works, we will include it in codi. information about building codi is available at [2]. an alternative would be to produce a proxy instead of the real instance and start the transaction lazily in the proxy before methods are invoked which should be executed within the transaction.
regards, gerhard [1] http://people.apache.org/~gpetracek/myfaces/codi/20110701_01.patch [2] https://cwiki.apache.org/confluence/display/EXTCDI/Building+CODI http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/1 Pieter Martin <[email protected]> > Hi, > > Currently I have gotten the following to work, using only request scoped db > instance and backing beans. > > public class FacesListener { > @Inject > NakedGraph db; > @Inject > Logger logger; > > public void beforeFacesRequest(@Observes @BeforeFacesRequest > FacesContext ctx) { > logger.fine("**beforeFacesRequest, setting db and starting > transaction"); > GraphDb.setDb(db); > db.startTransaction(); > } > > public void afterFacesRequest(@Observes @AfterFacesRequest FacesContext > ctx) { > logger.fine("**afterFacesRequest, stopping transaction and removing > db"); > db.stopTransaction(Conclusion.**SUCCESS); > GraphDb.remove(); > } > > } > > 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 transaction. > > 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 > active. > > Hope it makes some sense. > Thanks > Pieter > > > > 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<[email protected]**>: >> >>> 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 >>> >>> >> >
