Re: Conversations

[Pieter Martin]

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
[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.mar...@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.mar...@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