Thanks mario, (and Werner) thats this is more than enough!
On 2/28/07, Mario Ivankovits <[EMAIL PROTECTED]> 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
