myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ma...@ops.co.at>
Subject Re: MyFaces Fusion
Date Tue, 27 Feb 2007 22:45:25 GMT
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


Mime
View raw message