-
-
Notifications
You must be signed in to change notification settings - Fork 278
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
[JENKINS-47736] Introduced ClassFilter.setDefault #208
[JENKINS-47736] Introduced ClassFilter.setDefault #208
Conversation
@jglick It requires the JEP review, right? What is the current state of this process? |
I am not really sure. |
@oleg-nenashev FYI
|
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.
All the changes introduced here are reasonable even without JEP-200. The most interesting part of this JEP is changing the default behavior in the core. Blacklist filters just move the de-facto existing restrictions from the core.
Assuming the documentation gets polished a bit, I see no strict need to wait till JEP-200 is fully approved. So just a minor change requirement regarding the documentation.
public static final String FILE_OVERRIDE_LOCATION_PROPERTY = "hudson.remoting.ClassFilter.DEFAULTS_OVERRIDE_LOCATION"; | ||
|
||
private static final Logger LOGGER = Logger.getLogger(ClassFilter.class.getName()); | ||
|
||
protected boolean isBlacklisted(String name) { | ||
public boolean isBlacklisted(String name) { |
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.
Some Javadoc here would be helpful
return false; | ||
} | ||
|
||
protected boolean isBlacklisted(Class c) { | ||
public boolean isBlacklisted(Class c) { |
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.
same
@@ -15,6 +15,7 @@ | |||
import java.util.regex.PatternSyntaxException; | |||
|
|||
import javax.annotation.CheckForNull; | |||
import javax.annotation.Nonnull; | |||
|
|||
/** | |||
* Restricts what classes can be received through remoting. |
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.
IIUC with JEP-200 the same ClassFilter
will be also applied to XStream. I recommend documenting it here
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.
It already was applied to XStream, but yes it should be documented anyway.
/** | ||
* Changes the effective value of {@link #DEFAULT}. | ||
* @param filter a new default to set; may or may not delegate to {@link STANDARD} | ||
*/ |
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 TODO
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.
🐝 . As discussed in JEP-200, I will probably merge it ahead Remoting 3.16 even if the JEP is not approved. This part just enhances API and does not break anything.
It mostly just adds clearer APIs while leaving the deprecated Since there is no advantage to releasing the new API ahead of the core PR which uses it, I would still suggest doing them together, but up to you ultimately. @reviewbybees done anyway |
Agreed, the plugins need to be released ahead at least |
I have merged the PR with the current master and deployed the new snapshot: remoting-3.16-20171228.162243-1 |
dockerhub-notification-2.2.1 released today. |
Saw that, thanks @rsandell. |
Windows build is unstable due to the INFRA issue AFAICT:
Windows tests are green, so I do not care much: |
JEP-200 has been accepted. 🚢 🇮🇹 |
JENKINS-47736
@reviewbybees