On 2/7/07, Werner Punz wrote:
Jochen Wiedmann schrieb:
On 2/7/07, Werner Punz wrote:

Right idea wrong tier of the application stack, automated transaction
handling is in the realm
of the middleware, I highly can recommend to have a look at EJB3 and/or
Spring maybe even Seam.
Thing is automated transaction handling is already covered
by apis like Java Transaction API, the @Transactional annotation
of Spring or EJB
and or various other constructs in Spring or EJB.
JSF itself is mainly the view layer.
I must admit, that I have no idea about Spring. However, the Java
Transaction API, and/or EJB do clearly not cover these topics. I
wouldn't want to like to discuss this in detail, but I know of no
application where I didn't require a UserTransaction sooner or later.
And then I am back to my original question: How do I control it

ok if you want to bypass the app servers transaction mechanisms, then
you have various options:

First of all, you have to implement the rollback/commit and
opentransaction parts yourself in most cases.
Secondly there are various hook points to add it, if you want to have it
semi generic in the view layer such as:

a) Write your own view handler which roots basically into the original
one, but deals with the transactions

b) use a generic opensessionin view filter or something similar which
hooks into the servlet api

c) write your own servlet filter to deal with it

d) Use the shale view controller which has clear callback points which
are always called and add your transaction code there

One option is out of question, if you want to use phase listeners for
it, forget it, phase listeners can be called but mustn't.

The others is up to your choice.

If you really do want to do something like this as you originally proposed
(by wrapping the call to the action method somehow), you can actually do
that as well. A JSF implementation provides a default ActionListener whose
basic purpose is to evaluate the value of the "action" property, treat a
literal string as an outcome or call through via a method binding, and then
do the navigation. You can register your own replacement for this listener
in faces-config.xml like this:

<action-listener>FQCN of my action listener class</action-listener>

You'll probably want to delegate to the standard registered listener to do
the action call and navigation stuff, wrapping this in whatever you want to
do for exception handling.

The Shale ViewController[1] package has an example of this[2] that
implements its own exception handling strategy, to give you an idea of how
you might roll your own.


[1] http://shale.apache.org/shale-view/

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 6 | next ›
Discussion Overview
groupusers @
postedFeb 7, '07 at 1:04p
activeFeb 7, '07 at 5:29p



site design / logo © 2018 Grokbase