-
Notifications
You must be signed in to change notification settings - Fork 14
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
-Dosgi.dataAreaRequiresExplicitInit=true doesn't work anymore #35
Comments
Just wondering what |
Okay I see it in |
I will explain later. I've found another issue that I would like to debug and understand first. |
No problem, let me know if I can assist here and thanks for this very detailed review! |
…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
Unfortunately exactly that is the problem. BasicLocation, if not explicitly set, resolves to default in org.eclipse.osgi.internal.location.BasicLocation.getURL(), and default in Equinox is defined as userhome/workspace, see org.eclipse.osgi.internal.location.EquinoxLocations.EquinoxLocations(). For the rest, see explanation in #36 commit. Example "bad" bundle that initializes workspace in parallel to the prompt: iloveeclipse/java-things@1dea941 |
Bundle uses immediate service to init workspace to default location, before prompt is even shown. See eclipse-platform/eclipse.platform.runtime#35
…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
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
Is |
Not really.
It is expected to be set by the final product that expectes user to select the workspace location and to make sure no code would init workspace to some (unexpected by user) default location. |
This was originally created as eclipse-equinox/equinox.bundles#21.
While reviewing eclipse-platform/eclipse.platform.resources#71 I've found, that I'm able to silently init a workspace (with default value) without specifying workspace location explicitly via prompt or
-data
argument, even if-Dosgi.dataAreaRequiresExplicitInit=true
is set in eclipse.ini.This is a regression, so bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=514333 is back.
I'm investigating where it was broken... 4.19 is OK, 4.20 is broken...
OK, regression is coming from
Ironically, commit message was
The start code for the plugin can be migrated to run inside Workspace without changing existing behaviour.
...The root cause is the default initialization order of
LocalMetaArea
andWorkspaceRoot
objects after the patch above. If theWorkspaceRoot
is created first, it silently initializes default location for workspace. I will push a patch.The text was updated successfully, but these errors were encountered: