myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: Conversations
Date Fri, 01 Jul 2011 20:33:25 GMT
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 <pieter.martin@gmail.com>

> 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<pieter.martin@gmail.com**>
>>>>
>>>>  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<pieter.martin@gmail.com****>:
>>>>>>
>>>>>>  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
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message