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
Environmentvariableextension securitymanager tests #242
Environmentvariableextension securitymanager tests #242
Conversation
For documentation:
|
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
* because junit uses reflection and the default SecurityManager prevents that. | ||
*/ | ||
private void executeWithSecurityManager(Runnable runnable) { | ||
Policy.getPolicy().refresh(); |
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.
Does something like that needs to be called after the SystemProperty java.security.policy is reverted after the test?
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.
According to the official Oracle Java SE documentation
The
refresh
method causes the policy object to refresh/reload its data. This operation is implementation-dependent. For example, if the policy object stores its data in configuration files, callingrefresh
will cause it to re-read the configuration policy files. If a refresh operation is not supported, this method does nothing. Note that refreshed policy may not have an effect on classes in a particular ProtectionDomain. This is dependent on the Policy provider's implementation of theimplies
method and its PermissionCollection caching strategy.
To me, this reads like you should call it to properly reset the policy?
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.
If you want to test if resetting the policy works as expected, you should probably add a new test for that and add @Order
to your suite. Here is a blog post from Baeldung on that topic.
I am very inexperienced with the SecurityManager. If someone has better ideas how to handle this please share it with me. |
sidenote: i think this security thingy quiet interesting, and i am curious, beside this usecase with the policy - do you/we think that this might be a possible junit extension? we could generate a ticket out of that, and evaluate options, but it looks like something which could be useful. just an idea i came up while reading through this |
In general I could imagine such an extension but as I stated above I do not have much experience with the SecurityManager so I hope someone with more of a grasp on the topic can give some input. I think it would be good to create a ticket/issues for that to have a place for discussions if this PR will go away. |
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.
To be honest I don't know anything about this topic and I don't know if I find time to read into it. So I ask @aepfli and @nicolaiparlog for their review.
haha me neither - i will try to check today |
*/ | ||
private void executeWithSecurityManager(Runnable runnable) { | ||
Policy.getPolicy().refresh(); | ||
SecurityManager securityManager = System.getSecurityManager(); |
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.
I'd have named this variable original
. Everywhere it is used it is clear that it's a SecurityManager
, so naming it securityManager
is redundant - however System.setSecurityManager(original)
clearly communicates that we reset (and not modify) the SecurityManager
.
This is just a sidenote, don't feel the need to modify the PR just for this.
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.
I'd have named this variable
original
. Everywhere it is used it is clear that it's aSecurityManager
, so naming itsecurityManager
is redundant - howeverSystem.setSecurityManager(original)
clearly communicates that we reset (and not modify) theSecurityManager
.
This is just a sidenote, don't feel the need to modify the PR just for this.
I would not rename the variable! It only seems redundant because of Java 8. With 10+, using var at this section it would not be clear what a variable with the name original
holds.
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.
I mean, even with var
it would look like this:
var original = System.getSecurityManager();
// ... other code ...
System.setSecurityManager(original);
Seems clear to me?
…extension-securitymanager-tests # Conflicts: # src/test/java/org/junitpioneer/jupiter/EnvironmentVariableUtilsTests.java
- changed exception handling so no exception is hidden if could not modify environment variables - adjust comment setInSystemEnvClass because it also works on osx
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
Finally took some time to look at this, @Hancho2009. Sorry for letting it sit for nigh three months. Looks good to me! 😃 Proposed commit message:
|
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.
LGTM
@nicolaiparlog no problem |
resolves #241
I hereby agree to the terms of the JUnit Pioneer Contributor License Agreement.