Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SEC-1897: Remove raw types from AbstractAccessDecisionManager implementations #2124

Closed
spring-issuemaster opened this issue Jan 24, 2012 · 4 comments

Comments

@spring-issuemaster
Copy link

@spring-issuemaster spring-issuemaster commented Jan 24, 2012

Harald Wellmann (Migrated from SEC-1897) said:

Updated Description

AbstractAccessDecisionManager, AffirmativeBased, ConsensusBased, and UnanimousBased should use generic types for AccessDecisionVoter

h1. Original Description

After upgrading from Spring Security 3.0.6 to 3.1.0, I can no longer construct an AffirmativeBased without compiler warnings.

My old code using the default constructor and setDecisionVoters() now causes deprecation warnings.

The new constructor AffirmativeBased(List<AccessDecisionVoter> decisionVoters) omits the type argument of AccessDecisionVoter<S> which is also new in 3.1.0. Using the new constructor, I get a rawtypes warning.

Passing a List<AccessDecisionVoter<?>> to the constructor even causes a compile error. I think the new constructor should have been AffirmativeBased(List<AccessDecisionVoter<?>> decisionVoters). Was there a good reason for leaving out the type parameter?

@spring-issuemaster

This comment has been minimized.

Copy link
Author

@spring-issuemaster spring-issuemaster commented Jul 25, 2012

Rob Winch said:

This seems more like an improvement rather than a bug as it is not impacting an behavior. Unfortunately updating it now would cause incompatibilities. For example, the following works right now but would not after the proposed changes:

List<AccessDecisionVoter> adv = ...;
new AffirmationBasedDecisionVoter(adv);

With the above in mind, this is going to be pushed to the 3.2.0.M1 release as an improvement.

Out of curiosity is there a reason you are programmatically accessing AffirmativeBased? I would expect most would create using Spring Configuration. This is more of a curiosity factor to get an understanding of how things are being used.

@spring-issuemaster

This comment has been minimized.

Copy link
Author

@spring-issuemaster spring-issuemaster commented Jul 26, 2012

Harald Wellmann said:

Out of curiosity is there a reason you are programmatically accessing AffirmativeBased? I would expect most would create using Spring Configuration.

Spring Configuration is no longer synonymous with XML. We're now using Spring 3.1 Java configuration without any XML definitions throughout our projects, and it is rather sad that Java Config still seems to be a second-class citizen for Spring Security.

@spring-issuemaster

This comment has been minimized.

Copy link
Author

@spring-issuemaster spring-issuemaster commented Jul 26, 2012

Rob Winch said:

Thanks for sharing that you are using Java Config with Spring Security. You may be interested in watching/voting for SEC-1953 which intends to deliver Java config to Spring Security for 3.2

@spring-issuemaster

This comment has been minimized.

Copy link
Author

@spring-issuemaster spring-issuemaster commented Nov 20, 2014

Rob Winch said:

User's should now use:

List<AccessDecisionVoter<? extends Object>> voters = ...

ConsensusBased adm = new ConsensusBased(voters);
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.