myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Myfaces Wiki] Update of "HibernateAndMyFaces" by WernerPunz
Date Wed, 10 Aug 2005 16:17:37 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The following page has been changed by WernerPunz:
http://wiki.apache.org/myfaces/HibernateAndMyFaces

The comment on the change is:
first part of rewrite

------------------------------------------------------------------------------
  
  == Basic Mechanisms ==
  
- The first and foremost problem of having to integrate Hibernate with JSF is that you need
a controlled session and transaction handling.
+ The first and foremost problem of having to integrate Hibernate with JSF is that a controlled
session and transaction handling is needed.
- There are various ways to accomplish that, either you do it manually, or you do it automatically
via some kind of automatic program control.
+ There are various ways to accomplish that, it either can be done manually or automatically
via some kind of automatic program control.
+ 
- The manual way can be done from the backend beans at the various stages of the control flow
and basically uses all the mechanisms described
+ The manual way can be achieved within the backend beans at the various stages of the control
flow and basically uses all the mechanisms described
  in the [http://www.hibernate.org/5.html Hibernate Documentation].
  
  This strategy is cumbersome and problematic because it has to many points where the implementor
can cause a significant error in the session
  open/closing flow. (for instance a forgotten transaction finalizer can cause a severe interruption
and a tangling session which might 
  never be closed)
  
+ The same goes for the transaction handling. The transaction handling can be done manually
as described in the Hibernate documentation, but this approachi is errpr prone often causes
huge amounts of transactional code duplication.
+ Hence, an automated approach to cover this are is recommended, due to the additional timesaving
and code reduction which can be gained.
- The same goes for the transaction handling, you can do the transaction handling manually
as described in the Hibernate documentation
- but be prepared that you basically have programming errors and often huge amounts of transactional
code duplication.
- The recommendation from the author of this document is, try to go for automated mechanisms
as much as possible. It saves time
- and errors and reduces problems caused by the additional code.
  
  == Automated Mechanisms ==
  
@@ -56, +55 @@

  
  The most often used case probably is the one session per request appraoch.
  
- The idea is relatively simple, you start the session generation/recycling cycle, at the
beginning of a request, and as soon as one request terminates one way
+ The idea is relatively simple. the session generation/recycling cycle can be started at
the beginning of a request, and as soon as one request terminates one way
  or the other (in a normal or error condition) the session has to be closed/pushed back into
the recycle me state.
- There are various ways to achieve this behavior. All we need is a clearly defined, beginning
of the cycle ending of the cycle conjunction point.
+ There are various ways to achieve this behavior. All which is needed, is a clearly defined,
beginning of the cycle ending of the cycle conjunction point.
- The main culprit is, that the JSF API at the first sight does not define such things. But
in fact it does, but on a level where you do not expect it.
+ The main problem is, that the JSF API at the first sight does not define such things. But
in fact it does, but on a level where you do not expect it.
  But we will try to cover it from another angle first
  
  === One Session per Request via Servlet Filters ===
@@ -70, +69 @@

  
  So basically, this is a common way, to do it, there must be an implementation of such a
thing already existing out there?
  
- Yes indeed there is, you can find an almost unknown filter for this in the [http://www.springframework.org
Spring Framework] it is called the
+ Yes indeed there is, and can be found in the [http://www.springframework.org Spring Framework]

  
  it is called the OpenSessionInViewFilter
  
- The usage is relatively simple, although it enforces you to introduct the Spring Framework
into your mix of base frameworks.
+ The usage is relatively simple, although it enforces introduction of the Spring Framework
into your mix of base frameworks.
- All you need is two entries in the web.xml and you have the pattern enabled.
+ All which is needed is two entries in the web.xml and the pattern is enabled.
  
  {{{
  <filter>
@@ -90, +89 @@

  }}}
  
  If you already have a working spring/hibernate configuration all you need to do is to hadd
these lines to your project
- and every request which goes into a jsf file automatically is under full session scope,
without having to add a single
+ and every request which goes into a jsf file automatically is under full session scope,
without having to add a single line of code. 
- line of code. 
  
  === Problems ===
  
@@ -109, +107 @@

  NOTE: This filter will by default not flush the Hibernate Session, as it assumes to be used
in combination with business layer transactions that care for the flushing, or HibernateAccessors
with flushMode FLUSH_EAGER. If you want this filter to flush after completed request processing,
override closeSession and invoke flush on the Session before closing it. Note that closeSession
will just be invoked in single session mode! 
  }}}
  
- The other problem is, that you often need access to the hibernate facilites, this problem
can be solved by marrying spring and JSF. To do this, there are currently two APIs one is
provided by Spring and very basic, the alternate one is a [http://jsf-spring.sourceforge.net/
separate sideproject] currently hosted on sourceforge.
+ The other problem is, that you often access to the hibernate facilites is needed, this problem
can be solved by marrying spring and JSF. To do this, there are currently two APIs one is
provided by Spring and very basic, the alternate one is a [http://jsf-spring.sourceforge.net/
separate sideproject] currently hosted on sourceforge.
+ 
  At the time of writing this, the JSF-Spring project should be seriously considered over
the spring internal JSF bindings, it is much better and much more extensive.
  
+ Once both APIs are integrated MyFaces beans can be used from Spring and vice versa. Automated
access to the Spring ApplicationContext can be gained, by defining beans which implement the
ApplicationContextAware interface (probably they have to be defined them as spring beans)
and /or you can use the DAO base classes of spring can be used to inherit the dao functionality
in the jsf apps DAOs.
- Once you have integrated both APIs you can use MyFaces beans from Spring and vice versa.
You can get automated access to the Spring ApplicationContext, by defining beans which implement
the ApplicationContextAware interface (you probably have to define them as spring beans) and
/or you can use the 
- DAO base classes of spring to inherit the dao functionality in your jsf apps DAOs.
  
  
  === Automated transaction handling ===
  
- Once you are at that stage you have two options to do transaction handling, manual one or
automated one.
+ Once this stae is reached, two options to do transaction handling are available, a manual
one or automated one.
  
  The manual approach has different options
  
@@ -129, +127 @@

  The first two approaches are described in the Hibernate manual and in the spring manual
in a platform agnostic way. The third approach to work properly with JSF needs some pattern
adjustment.
  
  
- Patterns we needed for the approach:
+ Patterns neededed for the approach:
  
- We distinctively have to split between UI logic and application logic to have full control
over the transactional flow. That means in the backing beans which are directly docket to
the forms, no real application logic should be bound. The main problem is, that Spring uses
some kind of proxy mechanism to enable the AOP and the transactionaly handling, which intervenes
with precompiled logic in the JSF framework to some extent.
+ There has to be a clear split between UI logic and application logic to gain full control
over the transactional flow. IE in the backing beans which are directly docket to the forms,
no real application logic should be performed. The main problem is, that Spring uses some
kind of proxy mechanism to enable the AOP and the transactionaly handling, which intervenes
with precompiled logic in the JSF framework to some extent.
  
  Hence the flow of your application should go the following way:
  
@@ -140, +138 @@

  }}}
  
  
- It does not matter if you combine the BOs and the DAOs or go for a split approach, the main
key is, keep the transactional scope out of the JSF UI code, otherwise there might be problems
wrapping the needed
+ It does not matter if the BOs and the DAOs are combined or a split approach is targetted,
the main key is to keep the transactional scope out of the JSF UI code, otherwise there might
be problems wrapping the needed aspect proxies around the code.
- aspect proxies around the code.
  
  
  The transactional boundary might look like this (picture will follow):
@@ -150, +147 @@

  backing bean with strict ui logic and jsf related code |'''transaction boundary'''| business
object under transactional scope with the business logic
  }}}
  
- Depending on the JDK you use you can use different mechanisms to put your access code under
Hibernate/Spring transactional control.
+ Depending on the JDK different mechanisms can be used to put your access code under Hibernate/Spring
transactional control.
  
  The JDK 5.0 approach can use annotations to put an accessor method of your business object
under automated transactional control, to the time of this writing 
  springs transactional annotation support was in beta stage, see this [http://blog.exis.com/colin/archives/2005/07/18/spring-12s-java-5-based-transaction-annotations/
blog] for more information.
  This approach, however only works with Spring 1.2+ and Hibernate 3 in conjunction with JDK
5.0.
  
- For an older approach you can use the Spring based AOP transactional mechanisms:
+ For an older approach the Spring based AOP transactional mechanisms can be used:
  
  {{{
  <bean id="businessObject" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">

Mime
View raw message