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 <[email protected]>
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
