hi pieter, great! no - just the window-id gets restored a bit earlier (at least the first attempt). conversations get started as soon as you access them (nothing changed here).
i don't expect side-effects since there isn't a big difference, however, i'll create a jira issue for the improvement and we have to test it carefully. @window-id: i guess it would really help you, if you are using h:link instead of a plain html link as mentioned in the previous mail-thread. what you are doing sounds interesting. would be nice to read a blog entry about it! regards, gerhard 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]> > Ah damm, I missed the window url parameters again, its working fine. > > Pieter > > > On 01/07/2011 22:26, Pieter Martin wrote: > >> Hi, >> >> I just noticed for every request the conversation scoped producer is >> called. And the disposer not. I am expecting the producer only to be called >> once the conversation has timed out or been closed. >> >> Is my understanding here correct? >> >> Thanks >> Pieter >> >> On 01/07/2011 22:14, Pieter Martin wrote: >> >>> Hi, looks like it worked. >>> >>> I can now inject a conversation scoped db instance into the faces >>> listener set the threadvar and start the transaction. >>> >>> To clarify, is codi now starting a conversation before calling the >>> beforeRequest observer? >>> >>> Many thanks >>> Pieter >>> >>> >>> On 01/07/2011 20:09, Gerhard Petracek wrote: >>> >>>> 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<http://people.apache.org/~gpetracek/myfaces/codi/20110701_01.patch> >>>> [2] https://cwiki.apache.org/**confluence/display/EXTCDI/** >>>> Building+CODI<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 >>>>>>> >>>>>>> >>>>>>> >>> >> >
