-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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-2083: Created a class that allows filtering of immutable collections... #19
Conversation
@matsev Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
@matsev Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
…ecation-warnings Upgrade github-pages gem to fix deprecation warnings
final MethodSecurityExpressionOperations rootObject = (MethodSecurityExpressionOperations) ctx.getRootObject().getValue(); | ||
final boolean debug = logger.isDebugEnabled(); | ||
List retainList = new ArrayList(filterTarget.size()); | ||
if (debug) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this tow ifs could be combined:
if(debug){
-
logger.debug("Filtering with expression: " + filterExpression.getExpressionString());
-
logger.debug("Filtering collection with " + filterTarget.size() + " elements");
-
}
@matsev Thank you for signing the Contributor License Agreement! |
@matsev I'm moving the discussion from gh-2316 to this thread for better visibility.
Let us know if you are interested in modifying the PR according to the comment above. |
@eleftherias I am sorry, but I have no intention of updating the PR. After reading back, I recall the the problem I had back then, but I changed projects a long time ago. Supporting immutable collections still seems like good idea though, feel free to modify the PR in any way you find suitable. |
This is a suggestion on how the suggestion in https://jira.springsource.org/browse/SEC-2083 can be implemented. I was hesitating whether or not to extend the DefaultMethodSecurityExpressionHandler for this use case, or refactor it to form an AbstractMethodSecurityExpressionHandler that could be extended. Personally, I prefer the latter, but with the provided solution no existing code is changed.