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 <[email protected]> > 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<[email protected]**> >> >> 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<[email protected]****>: >>>> >>>> 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 >>>>> >>>>> >>>>> >
