myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <>
Subject Re: MyFaces Fusion
Date Tue, 27 Feb 2007 23:00:43 GMT
Aaresh feel free to contact me via gtalk if you need help.
I am pretty far along in my app already, I have covered most usecases
you run into a typical app.


Arash Rajaeeyan schrieb:
> Thanks mario, (and Werner)
> thats this is more than enough!
> On 2/28/07, *Mario Ivankovits* <
> <>> wrote:
>     Hi Arash!
>     > just give me some hints if possible
>     > I have two more days to finish this part of the book I am writing and
>     > I am interested to replace the seam framework I used in my example
>     > with fusion (or what ever it will be called in future)
>     > I have used only seam for integration with JPA, and it looks like I
>     > can replace it.
>     O-K I'll try:
>     For the installation you have to configure the conversation scope in
>     spring, for this you could have a look at
>     fusion/examples/src/main/webapp/WEB-INF/applicationContext.xml
>     As might see, the conversation scope is configured using an advice, the
>     persistentContextConversationInterceptor.
>     This interceptor holds the entity manager for a conversation and is
>     responsible to configure the thread.
>     Every bean configured in "conversation" scope (using
>     scope="conversation") will get a new entity manager.
>     If you used spring before, your knowledge about daos wont change.
>     Each conversation bean has to have the <aop:scoped-proxy/> marker. This
>     creates a proxy so that - even if you end a conversation - you can work
>     with this bean - but on an new instance then.
>     You can use the conversation scoped bean directly as your backing bean
>     for the view, this is the common case if you have to deal with a single
>     page only.
>     If you have a wizzard like pageflow you'll typically create a
>     conversation scope bean which you inject into your request scope backing
>     bean then.
>     The method in your conversation bean which will issue an update has to
>     be annotated with @Transactional - you can change your entites in not
>     annotated methods too, but then they are not flushed - the flush is
>     delayed unit a @Transactional method has been invoked.
>     That way the entity manager will issue a commit() at the end of the
>     method.
>     Tha can also be the point where you end a conversation, from within the
>     conversation bean you can access the current conversation using
>     Conversation.getCurrentInstance()
>     The conversation can also be invalidated(), which means the next access
>     to the bean instance will see an new empty one. There are strategies to
>     "restart" a conversation too.
>     The point is that you use the (well known) strategies of spring to get
>     access to the entity manager, and in JPA they are the standardized.
>     Fusion "just" configures spring so that it will see the associated
>     entityManager for the to-be-invoked conversation.
>     I am not sure if I manged to make things clearer now - all in all its
>     the spring configuration which you have to make correct, afterwards
>     there are just a handful of patterns which you should follow to make the
>     most use out of fusion.
>     Ciao,
>     Mario
> -- 
> Arash Rajaeeyan

View raw message