Added check for not intended default workspace location use (#35) #36
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Apr 22, 2022
Closed
bjhargrave
reviewed
Apr 22, 2022
| } | ||
| if (!location.isSet()) { | ||
| boolean explicitInitRequired = Boolean | ||
| .valueOf(getBundleContext().getProperty(PROP_REQUIRES_EXPLICIT_INIT)); |
There was a problem hiding this comment.
Suggested change
| .valueOf(getBundleContext().getProperty(PROP_REQUIRES_EXPLICIT_INIT)); | |
| .parseBoolean(getBundleContext().getProperty(PROP_REQUIRES_EXPLICIT_INIT)); |
No need to unbox.
…platform#35) See original bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=514333 that was only partly fixed. The original fix added -Dosgi.dataAreaRequiresExplicitInit=true system property and changed org.eclipse.core.internal.runtime.DataArea in the way that it doesn't allow to initialize itself if the workspace location was not explicitly specified yet - either via -data or via workspace selection prompt. But the fix in DataArea does not work if bad client code calls Platform.getLocation() *before* calling Plugin.getStateLocation(), because Platform.getLocation() doesn't run into changed DataArea code at all. Exact this happened in commit eclipse-platform/eclipse.platform.resources@a8a8d82 where workspace init order was slightly changed: original code initialized LocalMetaArea first (which then failed as supposed in assertLocationInitialized() if workspace was not set yet), and after that initialized WorkspaceRoot (which uses Platform.getLocation() after the check). Changed code initialized WorkspaceRoot first, and because this uses Platform.getLocation(), the code silently initializes default workspace location even if -Dosgi.dataAreaRequiresExplicitInit=true is set. The current fix makes sure that if the system flag is given, we disallow silent workspace location initialization by adding similar check in Platform.getLocation(). Fixes issue eclipse-platform#35
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See original bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=514333
that was only partly fixed.
The original fix added -Dosgi.dataAreaRequiresExplicitInit=true system
property and changed org.eclipse.core.internal.runtime.DataArea in the
way that it doesn't allow to initialize itself if the workspace location
was not explicitly specified yet - either via -data or via workspace
selection prompt.
But the fix in DataArea does not work if bad client code calls
Platform.getLocation() before calling Plugin.getStateLocation(),
because Platform.getLocation() doesn't run into changed DataArea code at
all.
Exact this happened in commit
eclipse-platform/eclipse.platform.resources@a8a8d82
where workspace init order was slightly changed: original code
initialized LocalMetaArea first (which then failed as supposed in
assertLocationInitialized() if workspace was not set yet), and after
that initialized WorkspaceRoot (which uses Platform.getLocation() after
the check). Changed code initialized WorkspaceRoot first, and because
this uses Platform.getLocation(), the code silently initializes default
workspace location even if -Dosgi.dataAreaRequiresExplicitInit=true is
set.
The current fix makes sure that if the system flag is given, we disallow
silent workspace location initialization by adding similar check in
Platform.getLocation().
Fixes issue
#35