myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: Conversations
Date Fri, 01 Jul 2011 18:39:27 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message