Hi Dave,
Interesting. I'd love to see an example added in the "User
Additions" part of the site!
Will try to do that soon. It does require that your Stripes
ActionBeans be Spring-managed (by any of the means discussed in this
thread already). Once that's set up, then the security approach is the
same as the annotation examples in the Spring Security reference doc.
Agreed. Unfortunately in my case we have experienced as well as
beginner developers on our projects. We also start projects with one
team and end up coming back a few months later with another team.
This leads us to employ rather strict "layer" (and coding)
conventions so that everyone can 1. find their way around easily
2. not have to think when to start a transaction
(it's a service method named save*, update*, find* etc.)
Pretty much as I describe in my Stripes Spring JPA guide :
http://www.stripesframework.org/display/stripes/Stripes+Spring+JPA
I'd love to get some feedback!
That's a helpful guide :)
Although it doesn't include Spring transaction details, I do have one
bit of feedback on the transaction approach you mention in your email:
I'm not keen on using method naming patterns for defining transaction
boundaries, because it constrains you to naming your methods within
those patterns. That might not be an issue on DAO's, but it might be
inconvenient on use-case oriented controllers/services.
What I do instead, is have an abstract parent for controllers,
services, dao's etc. Then I use Spring transaction annotations like so:
1) Define a default transaction behavior for the descendants, using a
class-level annotation:
@Transactional(propagation = Propagation.REQUIRED)
public abstract class BaseService {
}
2) Add other transaction behavior on descendant classes, or individual
methods when they need to vary from the inherited default:
public class FooService extends BaseService implements IFooService {
@Transactional(readOnly = true, propagation = Propagation.SUPPORTS)
public List<Foo> listAll() {
// <snip>
}
}
I suppose the main disadvantage of my approach is the extra effort of
annotating the methods whose transactional behavior need to vary from
the default.
Chris.
------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
