-
-
Notifications
You must be signed in to change notification settings - Fork 101
added required changes for logging blacklisted features #899
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
added required changes for logging blacklisted features #899
Conversation
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.
good stuff, thanks 😄 and welcome to the project 👍
return !featureIdentifierBlacklist.contains(featureId); | ||
boolean isBlackListed = featureIdentifierBlacklist.contains(featureId); | ||
if (isBlackListed) { | ||
logger.info(String.format("%s is blacklisted 😥", featureId)); |
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.
- use the loggers own formatting api, not urs (otherwise the string is also computed if info is disabled) -
logger.info("{} is blacklisted", featureId)
- id change the text slightly for better UX into
Feature {} is disabled.
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.
👍
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.
An idea would be make so the blacklist itself filter the features, so logging would be easier:
isEnabled would be left untouched, and a new method would be added
class FeatureBlacklist<T> {
...
public <F> Stream<F> disableMacthing(Stream<F> features, Function<T, F> idExtractor) {
return features.filter(f -> {
T id = idExtractor.apply(f);
if(this.isEnabled(id)) {
return true;
} else {
logger.info("{} is blacklisted 😥", id);
return false;
}
});
}
}
Features.java use case:
return blacklist.disableMacthing(features.stream(), Feature::getClass).toList();
Code actions use case:
List<CodeAction> codeActions =
blacklist.disableMacthing(
Stream.of(new FormatCodeCommand(), new EvalCodeCommand(jshellEval),
f -> f.getClass().getName()
).toList();
@Alathreon incorporating the above change would introduce changes in class |
F isn't a generic that you put on the class, but I indeed forgot to declare it correctly, I modified my review message, it should be declared on the method directly.
No
This code is the same as the previous isEnabled idea, which we decided to not follow, so no |
@Alathreon, @Zabuzard added suggested changes, please review |
@adiChoudhary you didn't reverse the changes you did to isEnabled, and did you verify that it works ? |
sorry thats why i was seeing 2 log statements, will do that |
Reverted it back now |
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.
Since we won’t be using isEnabled
outside of the disableMatching
method, maybe we could in-line and remove it?
public boolean isEnabled(T featureId) { | ||
return !featureIdentifierBlacklist.contains(featureId); | ||
} | ||
|
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.
Please add Java doc here.
|
||
FeatureBlacklist<Class<?>> blacklist = blacklistConfig.normal(); | ||
return features.stream().filter(f -> blacklist.isEnabled(f.getClass())).toList(); | ||
return blacklist.disableMatching(features.stream(), Feature::getClass).toList(); |
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.
IMO this should be made Object::getClass
return !featureIdentifierBlacklist.contains(featureId); | ||
} | ||
|
||
public <F> Stream<F> disableMatching(Stream<F> features, Function<F, T> idExtractor) { |
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.
You should use Stream<? extends F>
and Function<? super F, ? extends T>
as it allows more flexibility
There's a new PR #980 that seems to be targetting the same issue, i assume this is not active anymore? Perhaps a polite reminder to author of new PR to check issues with maintainers beforehand. Otherwise there work might be a waste of effort. |
Is this PR nearly done, or it should be closed in favour of #980? Both seem to be inactive, and this one is at least passing all checks. I mean, this looks fine, maybe slightly overcomplicated since project should be readable by beginners, but I think we are long past that point hah. It's just a few lines anyway, seems like there is not a good reason to drag this out for 2 more months. ^^ |
merged #1048 |
added a boolean check to log blacklisted features