Bug 547496 - Using ResourcesPlugin in immediate service crashes Eclipse on startup
Summary: Using ResourcesPlugin in immediate service crashes Eclipse on startup
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 4.6   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Platform-Resources-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-21 03:16 EDT by Lucas Koehler CLA
Modified: 2020-03-23 15:34 EDT (History)
2 users (show)

See Also:


Attachments
.log in workspace after the startup crash (107.54 KB, text/plain)
2019-05-21 03:16 EDT, Lucas Koehler CLA
no flags Details
Minimal example plugin and feature as source projects (6.56 KB, application/zip)
2019-05-21 03:17 EDT, Lucas Koehler CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lucas Koehler CLA 2019-05-21 03:16:28 EDT
Created attachment 278672 [details]
.log in workspace after the startup crash

When installing a Plugin in the Eclipse Modeling Edition 2019-03 (but possible also other editions), which has an immediate OSGI Service that either directly or indirectly uses the org.eclipse.core.resources.ResourcesPlugin, the Eclipse instance crashes at startup with message "An error occurred. See the log file <log-file-location>".
In our case this happens because our service has a Reference to a service using EMF. As EMF seems to use the ResourcesPlugin, services using EMF cannot be used as immediate.
Interestingly, the error does not occur during the restart after installing the plugin. But starting Eclipse afterwards, it occurs every time.

I attached a minimal sample plugin and feature as well as the log file using this example.
The example contains the immediate OSGI service Immediate which references a service of interface ServiceInterface. The interfaces implementation TestService creates an EObject on activate.


The root exception seems to be the following (for the full stacktraces, see attached log file):

Root exception:
java.lang.IllegalStateException: The instance data location has not been specified yet.
	at org.eclipse.core.internal.runtime.DataArea.assertLocationInitialized(DataArea.java:59)
	at org.eclipse.core.internal.runtime.DataArea.getStateLocation(DataArea.java:136)
	at org.eclipse.core.internal.runtime.InternalPlatform.getStateLocation(InternalPlatform.java:534)
	at org.eclipse.core.runtime.Plugin.getStateLocation(Plugin.java:308)
	at org.eclipse.core.internal.resources.LocalMetaArea.<init>(LocalMetaArea.java:63)
	at org.eclipse.core.resources.ResourcesPlugin.start(ResourcesPlugin.java:481)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:815)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:808)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:765)
	at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1005)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:357)
	at org.eclipse.osgi.container.Module.doStart(Module.java:589)
	at org.eclipse.osgi.container.Module.start(Module.java:457)
	at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:471)
	at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:117)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:570)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:331)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:39)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:469)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:414)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:153)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.eclipse.emf.ecore.plugin.EcorePlugin.getWorkspaceRoot(EcorePlugin.java:1149)
Comment 1 Lucas Koehler CLA 2019-05-21 03:17:34 EDT
Created attachment 278673 [details]
Minimal example plugin and feature as source projects
Comment 2 Andrey Loskutov CLA 2019-05-21 03:21:17 EDT
I would say that's the problem of resources plugin - if one uses it, one should always specify workspace (-data argument).

It is kind of "was always there" precondition and AFAIK there is no way to use resources without it. Unlikely this will change, but if you have a good idea - you are welcome.
Comment 3 Lucas Koehler CLA 2019-05-21 03:42:07 EDT
Okay, I thought it was weird because I explicitly selected a workspace in Eclipse's workspace selection dialog. However, it seems it's just initialized too late.
Comment 4 Andrey Loskutov CLA 2019-05-21 03:45:35 EDT
(In reply to Lucas Koehler from comment #3)
> Okay, I thought it was weird because I explicitly selected a workspace in
> Eclipse's workspace selection dialog. However, it seems it's just
> initialized too late.

This is too late, the problem is that immediate service is triggering resource plugin init *before* the UI (and selection dialog) starts.