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 Fri, 01 Jul 2011 18:43:25 GMT
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<pieter.martin@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
>>>>>>
>>>>>>
>>>>>>


Mime
View raw message