You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Pieter Martin <pi...@gmail.com> on 2011/06/30 22:46:03 UTC
RE: Conversations
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
Re: Conversations
Posted by Pieter Martin <pi...@gmail.com>.
Sorry that was stupid, AbstractEntity is a interface with only
getName(), the concrete object however does have a setName.
Thanks
Pieter
On 01/07/2011 20:39, Gerhard Petracek wrote:
> hi pieter,
>
> i guess that would also happen with any other scope. please ensure
> that AbstractEntity#setName
> is implemented.
>
> 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<pi...@gmail.com>
>
>> Great, thanks, will give the patch a try.
>>
>> Right now I have the following exception happening.
>>
>> I have a producer
>> @Named("contextRoot")
>> @Produces
>> @ConversationScoped
>> public AbstractEntity getContextRoot() {
>> return db.getCompositeRoots().get(0);
>> }
>>
>> then in a jsf page I have
>>
>> <h:form id="mainForm">
>> <h:inputText id="rootLabel" value="#{contextRoot.name}" />
>> <h:commandButton value="Update" action="#{updateContextRoot.**update}" />
>> </h:form>
>>
>> @ConversationScoped
>> @Named("updateContextRoot")
>> public class UpdateContextRoot implements Serializable {
>> ...
>> public void update() {
>> logger.info("updated context root");
>> messageContext.addMessage(new DefaultMessage("Updated context root
>> succesfully"));
>> }
>> }
>>
>> SEVERE: An exception occurred
>> javax.faces.component.**UpdateModelException: javax.el.**PropertyNotWritableException:
>> /conversation/**testConversation1.xhtml at line 17 and column 75
>> value="#{contextRoot.name}": The class 'org.javassist.tmp.java.lang.**Object_$$_javassist_31'
>> does not have a writable property 'name'.
>> at javax.faces.component.UIInput.**updateModel(UIInput.java:397)
>> at javax.faces.component.UIInput.**processUpdates(UIInput.java:**298)
>> at javax.faces.component.**UIComponentBase.**processUpdates(**
>> UIComponentBase.java:1288)
>> at javax.faces.component.UIForm.**processUpdates(UIForm.java:**219)
>> at javax.faces.component.**UIComponentBase.**processUpdates(**
>> UIComponentBase.java:1288)
>> at javax.faces.component.**UIComponentBase.**processUpdates(**
>> UIComponentBase.java:1288)
>> at javax.faces.component.**UIViewRoot._**processUpdatesDefault(**
>> UIViewRoot.java:1325)
>> at javax.faces.component.**UIViewRoot.access$600(**UIViewRoot.java:75)
>> at javax.faces.component.**UIViewRoot$**UpdateModelPhaseProcessor.**
>> process(UIViewRoot.java:1427)
>> at javax.faces.component.**UIViewRoot._process(**UIViewRoot.java:1286)
>> at javax.faces.component.**UIViewRoot.processUpdates(**
>> UIViewRoot.java:770)
>> at org.apache.myfaces.lifecycle.**UpdateModelValuesExecutor.**execute(*
>> *UpdateModelValuesExecutor.**java:34)
>> at org.apache.myfaces.lifecycle.**LifecycleImpl.executePhase(**
>> LifecycleImpl.java:171)
>> at org.apache.myfaces.lifecycle.**LifecycleImpl.execute(**
>> LifecycleImpl.java:118)
>> at org.apache.myfaces.extensions.**cdi.jsf2.impl.listener.phase.**
>> CodiLifecycleWrapper.execute(**CodiLifecycleWrapper.java:94)
>>
>> Looks like the proxied contextRoot object is not right.
>>
>> Any idea whats going wrong?
>>
>> 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
>>>>>>
>>>>>>
>>>>>>
Re: Conversations
Posted by Gerhard Petracek <ge...@gmail.com>.
hi pieter,
i guess that would also happen with any other scope. please ensure
that AbstractEntity#setName
is implemented.
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 <pi...@gmail.com>
> Great, thanks, will give the patch a try.
>
> Right now I have the following exception happening.
>
> I have a producer
> @Named("contextRoot")
> @Produces
> @ConversationScoped
> public AbstractEntity getContextRoot() {
> return db.getCompositeRoots().get(0);
> }
>
> then in a jsf page I have
>
> <h:form id="mainForm">
> <h:inputText id="rootLabel" value="#{contextRoot.name}" />
> <h:commandButton value="Update" action="#{updateContextRoot.**update}" />
> </h:form>
>
> @ConversationScoped
> @Named("updateContextRoot")
> public class UpdateContextRoot implements Serializable {
> ...
> public void update() {
> logger.info("updated context root");
> messageContext.addMessage(new DefaultMessage("Updated context root
> succesfully"));
> }
> }
>
> SEVERE: An exception occurred
> javax.faces.component.**UpdateModelException: javax.el.**PropertyNotWritableException:
> /conversation/**testConversation1.xhtml at line 17 and column 75
> value="#{contextRoot.name}": The class 'org.javassist.tmp.java.lang.**Object_$$_javassist_31'
> does not have a writable property 'name'.
> at javax.faces.component.UIInput.**updateModel(UIInput.java:397)
> at javax.faces.component.UIInput.**processUpdates(UIInput.java:**298)
> at javax.faces.component.**UIComponentBase.**processUpdates(**
> UIComponentBase.java:1288)
> at javax.faces.component.UIForm.**processUpdates(UIForm.java:**219)
> at javax.faces.component.**UIComponentBase.**processUpdates(**
> UIComponentBase.java:1288)
> at javax.faces.component.**UIComponentBase.**processUpdates(**
> UIComponentBase.java:1288)
> at javax.faces.component.**UIViewRoot._**processUpdatesDefault(**
> UIViewRoot.java:1325)
> at javax.faces.component.**UIViewRoot.access$600(**UIViewRoot.java:75)
> at javax.faces.component.**UIViewRoot$**UpdateModelPhaseProcessor.**
> process(UIViewRoot.java:1427)
> at javax.faces.component.**UIViewRoot._process(**UIViewRoot.java:1286)
> at javax.faces.component.**UIViewRoot.processUpdates(**
> UIViewRoot.java:770)
> at org.apache.myfaces.lifecycle.**UpdateModelValuesExecutor.**execute(*
> *UpdateModelValuesExecutor.**java:34)
> at org.apache.myfaces.lifecycle.**LifecycleImpl.executePhase(**
> LifecycleImpl.java:171)
> at org.apache.myfaces.lifecycle.**LifecycleImpl.execute(**
> LifecycleImpl.java:118)
> at org.apache.myfaces.extensions.**cdi.jsf2.impl.listener.phase.**
> CodiLifecycleWrapper.execute(**CodiLifecycleWrapper.java:94)
>
> Looks like the proxied contextRoot object is not right.
>
> Any idea whats going wrong?
>
> 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
>>>>>
>>>>>
>>>>>
>
Re: Conversations
Posted by Pieter Martin <pi...@gmail.com>.
Great, thanks, will give the patch a try.
Right now I have the following exception happening.
I have a producer
@Named("contextRoot")
@Produces
@ConversationScoped
public AbstractEntity getContextRoot() {
return db.getCompositeRoots().get(0);
}
then in a jsf page I have
<h:form id="mainForm">
<h:inputText id="rootLabel" value="#{contextRoot.name}" />
<h:commandButton value="Update" action="#{updateContextRoot.update}" />
</h:form>
@ConversationScoped
@Named("updateContextRoot")
public class UpdateContextRoot implements Serializable {
...
public void update() {
logger.info("updated context root");
messageContext.addMessage(new DefaultMessage("Updated context
root succesfully"));
}
}
SEVERE: An exception occurred
javax.faces.component.UpdateModelException:
javax.el.PropertyNotWritableException:
/conversation/testConversation1.xhtml at line 17 and column 75
value="#{contextRoot.name}": The class
'org.javassist.tmp.java.lang.Object_$$_javassist_31' does not have a
writable property 'name'.
at javax.faces.component.UIInput.updateModel(UIInput.java:397)
at javax.faces.component.UIInput.processUpdates(UIInput.java:298)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1288)
at javax.faces.component.UIForm.processUpdates(UIForm.java:219)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1288)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1288)
at
javax.faces.component.UIViewRoot._processUpdatesDefault(UIViewRoot.java:1325)
at javax.faces.component.UIViewRoot.access$600(UIViewRoot.java:75)
at
javax.faces.component.UIViewRoot$UpdateModelPhaseProcessor.process(UIViewRoot.java:1427)
at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1286)
at javax.faces.component.UIViewRoot.processUpdates(UIViewRoot.java:770)
at
org.apache.myfaces.lifecycle.UpdateModelValuesExecutor.execute(UpdateModelValuesExecutor.java:34)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at
org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.execute(CodiLifecycleWrapper.java:94)
Looks like the proxied contextRoot object is not right.
Any idea whats going wrong?
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<pi...@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
>>>>
>>>>
Re: Conversations
Posted by Pieter Martin <pi...@gmail.com>.
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<pi...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
Re: Conversations
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <pi...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>
>
Re: Conversations
Posted by Pieter Martin <pi...@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
>>> [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<pi...@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
>>>>>>
>>>>>>
>>
>
Re: Conversations
Posted by Pieter Martin <pi...@gmail.com>.
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<pi...@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
>>>>>
>>>>>
>
Re: Conversations
Posted by Pieter Martin <pi...@gmail.com>.
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<pi...@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
>>>>
>>>>
Re: Conversations
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <pi...@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
>>>
>>>
>>
>
Re: Conversations
Posted by Pieter Martin <pi...@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<pi...@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
>>
>
Re: Conversations
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <pi...@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
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces