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