Wim,
One of the applications that I work on has 3 interception layers going
right now. Security, Transactions, and Monitoring. All interception is
done using DefaultAutoProxyCreator with Advisors declared as beans.
The interceptors are kept in a specific order using the "order"
attribute of the advisors (the order of your annotations doesn't enter
into it).
In setting all of this up I've found that Spring gets confused pretty
easily when the annotations are on the Impl, or mixed between the impl
and the interface. Especially when the beans are declared as you have
them; with a ProxyFactoryBean and Impl for the same instance hanging
out in the context.
What ended up solving all of our configuration woes was to put all of
the Annotations on the interfaces. The reasoning behind this is that
in most instances of navigating the BeanFactory, all Spring sees is
the interface. The question of wether to look at the interface or the
impl for the annotations is eliminated. The interface is always there
in plainsight with all the information needed.
We also segmented our ApplicationContext xml files into specific
areas. The reasoning for this answers your concern about leaving off
the transaction interceptor in some cases (I think). All of our
transaction configuration is in one file, all of the method level
security stuff is in another file, and our monitoring stuff is in a
third file. The Advisors for those realms are declared in those realm
specific files as well. The DefaultAutoProxyCreator is declared in a
fourth file, that is always included with the app. So, if we want to
leave out method level security we just leave out that file.
Wether or not the Annotations 'belong' on the interfaces is probably
in the same category as wether or not curly braces 'belong' on the
same line or not :)
Hope that helps,
-Ray
On 10/26/06, Wim Lambrecht <[EMAIL PROTECTED]> wrote:
> wow,
>
> i did include some typos my mail,
> excuse me,
> i'll correct them now:
>
> Wim Lambrecht schreef:
> > Hi,
> >
> > I have a java (service) interface and an implementation and i want to
> > apply transactional (using Springs @Transactional annotation) and
> > security (using Acegi's @Secured annotation) aspects on it.
> > I'm pretty sure i can manage to use then in a separate setup/deployment
> > (meaning: either transactional or secured), but both at the same time
> > does not give me the desired result.
> >
> > My setup:
> > - an java interface for my service
> > - an implementation of that service interface
> > - i want it to be secure and transactional guarded.
> > I must be honest: i'm actually using a manually configured
> > transactionale proxy (using TransactionProxyFactoryBean) in combinatie
> > with acegi's @Secured annotation (using auto-proxing via
> > DefaultAdvisorAutoProxyCreator and MethodDefinitionSourceAdvisor).
> > - the TransactionProxyFactoryBean is directly in front of my actual
> > service implementation
> > - the @Secured stuff is annotated on some methods on the service interface.
> >
> > public interface OrderService {
> >
> > @Secured({ROLE_ORDERMANAGER})
> > public void deleteOrder(Order o);
> >
> > //...
> > }
> >
> > public class StandardOrderService implements OrderService {
> >
> > OrderDAO orderDAO = ...
> >
> > public void deleteOrder(Order o) {
> >someOrderDAO.deleteOrder(o);
> > }
> >
> > }
> >
> > //spring-config extraction:
> > > class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
> >
> >
> >
> >
> >
> >
> >
> >
> > PROPAGATION_REQUIRED
> >
> >
> >
> >
> >
> >
> > // stuff (like DAO config etc)
> >
> > //spring-config extraction (END)
> >
> >
> > What happens:
> > (---> is 'target')
> > - my service implementation gets proxied, which is great:
> > $proxy12 (tx-proxy) > actual service implementation
> > - since the 'tx-proxy' also implements (i guess) my OrderService, it
> > gets secured-proxied, again 'great', that's what i like. But naturally
> > my service implementation also implements my OrderService interface, so
> > it gets secured-proxied as well. So, i end up with 2 security interceptions:
> > $proxy13 (sec-proxy on tx-proxy) ---> $proxy12 (tx-proxy) >
> > $proxy14 (second sec-proxy !) --->actual service implementation
> >
> >
> > What i desire:
> > - the best possible setup, so that calls to the service implementation
> > go through maximum 2 proxies, being: 1) the security front and 2) (ones
> > you're in) the transactional protection.
> > - i like to use the @Transactional approach instead, so that security and
> > transactional behavior can be annotated (no config-file fuzz).
> >
>
> > - this seems like a common behaviour, so i guess someone else must have
> > this needs too (and maybe already has a nice patterns in place).
> >
> > Questions (and suggestions of m
