Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (athena.apache.org: domain of pieter.martin@gmail.com
 designates 74.125.82.181 as permitted sender)
Message-ID: <4E0E2AB4.4040404@gmail.com>
Date: Fri, 01 Jul 2011 22:14:44 +0200
From: Pieter Martin <pieter.martin@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: MyFaces Discussion <users@myfaces.apache.org>
Subject: Re: Conversations
References: <4E0CE08B.70500@gmail.com>
 <BANLkTi=vncW4B_PmDUtUh6H-gOj0MUNOYQ@mail.gmail.com>
 <4E0DD495.1090509@gmail.com>
 <BANLkTimohxyGS3=iF49h+cNrVNxE=x6A0w@mail.gmail.com>
In-Reply-To: <BANLkTimohxyGS3=iF49h+cNrVNxE=x6A0w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
> [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<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
>>>>
>>>>