hi rainer, i agree with you, however, there was no agreement in the community to keep just @Secured. since @Secures is a generic binding, we refactored @Secured (now it's based on @Secures and isn't a std. cdi-interceptor any longer).
regards, gerhard 2013/4/9 Rainer Schön <rainer.sch...@mr-partner.ch> > Hi Gerhard > > I appreciated your quick reply, thanks. It is about what I thought when I > studied the documentation of seam security and CODI security. In my > opinion, the "@Secured" way provides the functionality needed and is > virtually self documenting by it's DecisionVoter concept. Why the effort, > to maintain two api for the same goal (apart the view-config integration > which only @Secured provides)? > > Regards, > Rainer > > > > > > Am 08.04.2013 21:04, schrieb Gerhard Petracek: > > hi rainer, >> >> @Secures came from seam3 and is a cdi like ~simple binding. >> @Secured is (now) based on @Secures and just a different style + offers >> more than that (e.g. the integration with the view-config). >> >> regards, >> gerhard >> >> >> >> 2013/4/8 Rainer Schön <deltasp...@mr-partner.ch> >> >> Hello, >>> >>> I am evaluating DS for a migration project java ee5 Seam -> java ee6. >>> Currently it is the security module that I am exploring (clone of >>> 0.4-incubating-SNAPSHOT / 9720bec commit and locally built / Java 7 SDK). >>> Some questions have arisen during my tests. I will begin with my first >>> discovery: >>> >>> - Secures and DecisionVoter seam to me somewhat redundant. What is the >>> idea behind this design decision? >>> >>> - Secures seams not to work with the type safe view configuration >>> feature. >>> Is this intentional or an anomaly? >>> >>> - If it is intentional, what are the considerations? >>> >>> Thanks in advance for a feedback >>> Rainer >>> >>> >>> >>> >>> >>> >> >
