myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pieter Martin <pieter.mar...@gmail.com>
Subject Re: Conversations
Date Mon, 04 Jul 2011 17:56:42 GMT
Not quite ready for the blogosphere yet. The project I am working on is 
a UML generation framework/tool. https://github.com/nakeduml. Currently 
we am adding support for using Graph databases as persistence. We are 
also moving from a EE/JPA/JTA environment to a Jetty/CODI/GraphDb one. 
So far things are going particularly well thanks to fantastic support 
from the communities.

Pieter

On 01/07/2011 22:33, Gerhard Petracek wrote:
> 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
View raw message