Odd error when installing update-site zip

[andrew-tram]

I'm developing an RCP application based on Eclipse 4.31 and Java 17. While the product builds, packages, and runs smoothly overall, I'm encountering an issue when installing update-site zips.

Error notifying registry change listener.
Error notifying registry change listener.
BundleContext is no longer valid org.eclipse.e4.ui.workbench_1.15.300.v20240124-0948 [1502]

and

An internal error occurred during: "Workbench Auto-Save Background Job".
org/eclipse/emf/ecore/resource/Resource

When attempting to install update-site zips, the process eventually triggers the "Restart Workbench" dialog as expected. However, upon confirming the restart, nothing happens. I have to manually close and relaunch the application. After restarting, the updates appear to have been successfully installed, but the restart mechanism itself seems unresponsive.

I thought it was related to this issue - #512, so I applied a patch to my product to incorporate the changes used to fix it. That did not make a difference.

Other things I've tried... In my Available Software Sites, I have the following:

I tried removing all of those update-sites, save for the file / zip I'm trying to install. No difference there. And for some reason WWD and other update-sites are being contacted. I do have WWD and other Eclipse Projects as part of my offering, but as you can see, those update-sites are not available or present in the Preferences. And the update-site I want to install does not contain any nested update-sites.

Interestingly enough, the only thing that did work is if "Contact all update sites..." is unchecked.

A lot of things are logged, so it's hard to tell what's really relevant, but the things that stick out to me are:

!MESSAGE UI thread waiting on a job or lock.
!STACK 0
java.lang.IllegalStateException: Call stack for thread main
	at java.base/sun.nio.fs.WindowsNativeDispatcher.GetFileAttributesEx0(Native Method)
	at java.base/sun.nio.fs.WindowsNativeDispatcher.GetFileAttributesEx(WindowsNativeDispatcher.java:390)
	at java.base/sun.nio.fs.WindowsFileAttributes.get(WindowsFileAttributes.java:307)
	at java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:251)
	at java.base/sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:110)
	at java.base/java.nio.file.Files.deleteIfExists(Files.java:1191)

!ENTRY org.eclipse.e4.core.di 4 0 2024-09-27 19:18:01.695
!MESSAGE Unable to process "Processor.partService": no actual value was found for the argument "EPartService".

!ENTRY org.eclipse.e4.core.di 4 0 2024-09-27 19:18:01.696
!MESSAGE Unable to process "SplitterAddon.ps": no actual value was found for the argument "EPartService".

!ENTRY org.eclipse.e4.core.di 4 0 2024-09-27 19:18:01.697
!MESSAGE Unable to process "TrimStack.partService": no actual value was found for the argument "EPartService".

!ENTRY org.eclipse.e4.ui.workbench 4 0 2024-09-27 19:18:01.698
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.eclipse.swt.SWTException: Invalid thread access
	at org.eclipse.swt.SWT.error(SWT.java:4922)
	at org.eclipse.swt.SWT.error(SWT.java:4837)
	at org.eclipse.swt.SWT.error(SWT.java:4808)
	at org.eclipse.swt.widgets.Widget.error(Widget.java:450)
	at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:370)
	at org.eclipse.swt.widgets.Shell.setModified(Shell.java:1871)
	at org.eclipse.ui.internal.handlers.SaveHandler.evaluate(SaveHandler.java:105)
	at org.eclipse.ui.internal.handlers.AbstractSaveHandler$1.evaluate(AbstractSaveHandler.java:54)
	at org.eclipse.ui.internal.services.EvaluationReference.evaluate(EvaluationReference.java:76)
	at org.eclipse.ui.internal.services.EvaluationReference.evaluate(EvaluationReference.java:106)
	at org.eclipse.ui.internal.services.EvaluationReference.changed(EvaluationReference.java:100)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:105)
	at org.eclipse.e4.core.internal.contexts.EclipseContext.processScheduled(EclipseContext.java:358)
	at org.eclipse.e4.core.internal.contexts.EclipseContext.remove(EclipseContext.java:332)
	at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.serviceChanged(EclipseContextOSGi.java:129)
	at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:133)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:985)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151)
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:956)
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:890)
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:245)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:952)

!ENTRY org.eclipse.ui 4 0 2024-09-27 19:18:01.932
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry object
	at org.eclipse.core.internal.registry.RegistryObjectManager.basicGetObject(RegistryObjectManager.java:293)
	at org.eclipse.core.internal.registry.RegistryObjectManager.getObject(RegistryObjectManager.java:283)
	at org.eclipse.core.internal.registry.ConfigurationElementHandle.getConfigurationElement(ConfigurationElementHandle.java:29)
	at org.eclipse.core.internal.registry.ConfigurationElementHandle.getAttribute(ConfigurationElementHandle.java:38)
	at org.eclipse.ui.internal.services.RegistryPersistence.readRequired(RegistryPersistence.java:428)
	at org.eclipse.ui.internal.services.RegistryPersistence.readRequired(RegistryPersistence.java:407)
	at org.eclipse.ui.internal.menus.LegacyActionPersistence.readEditorContributions(LegacyActionPersistence.java:574)
	at org.eclipse.ui.internal.menus.LegacyActionPersistence.read(LegacyActionPersistence.java:426)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4047)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3663)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:823)
	at org.eclipse.jface.window.Window.open(Window.java:799)

!ENTRY org.eclipse.e4.ui.workbench.renderers.swt 4 2 2024-09-27 19:18:02.049
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.e4.ui.workbench.renderers.swt".
!STACK 0
org.eclipse.e4.core.di.InjectionException: org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry object
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:68)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:298)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:232)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:174)
	at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.setEnabled(HandlerServiceHandler.java:91)
	at org.eclipse.core.commands.Command.setEnabled(Command.java:856)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.canExecute(HandlerServiceImpl.java:170)
	...
Caused by: org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry object
	at org.eclipse.core.internal.registry.RegistryObjectManager.basicGetObject(RegistryObjectManager.java:293)
	at org.eclipse.core.internal.registry.RegistryObjectManager.getObject(RegistryObjectManager.java:283)

!ENTRY org.eclipse.e4.ui.workbench 4 0 2024-09-27 19:18:02.050
!MESSAGE Internal error during tool item enablement updating, this is only logged once per tool item.
!STACK 0
org.eclipse.e4.core.di.InjectionException: org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry object
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:68)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:298)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:232)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:174)
	at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.setEnabled(HandlerServiceHandler.java:91)
	at org.eclipse.core.commands.Command.setEnabled(Command.java:856)
...
Caused by: org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry object
	at org.eclipse.core.internal.registry.RegistryObjectManager.basicGetObject(RegistryObjectManager.java:293)
	at org.eclipse.core.internal.registry.RegistryObjectManager.getObject(RegistryObjectManager.java:283)
	at org.eclipse.core.internal.registry.ConfigurationElementHandle.getConfigurationElement(ConfigurationElementHandle.java:29)
	at org.eclipse.core.internal.registry.ConfigurationElementHandle.getContributor(ConfigurationElementHandle.java:162)

[laeubi]

I'm developing an RCP application based on Eclipse 4.31 and Java 17. While the product builds, packages, and runs smoothly overall, I'm encountering an issue when installing update-site zips.

Can you be more specific what "installing update-site zips" refers to as one can't "install" a zip file or an update-site. If you refer to the ues of update-site-urls that point to a zip file, I strongly would discourage such usage, just simply expand the zip file for maximum compatibility, beside that using the latest Eclipse release will get you the best chance to profit from bugfixes and possibly analysis of problems.

[andrew-tram]

@laeubi ,

What I meant was choose a zip that's an update-site from the Add Repository panel from the Archive choice.

Or something like "p2 Install Repository" from here https://jazz.net/downloads/workflow-management/releases/7.0.3?p=allDownloads if that's a more accessible example of the update-site zip on my local machine.

Unfortunately, we're not in a possible to build our product against the latest release of Eclipse and use the one that's available every March. So, if there was a critical fix in newer release, we would port that to our Eclipse 4.31 base and apply it as a patch.

[merks]

Note that just a few weeks ago I made some improvements related to zipped update sites:

eclipse-platform/eclipse.platform.ui#2265

I don't believe there is an actual problems with updating from a zipped update site because that whole process worked well for me while testing to ensure that a file:jar URL is preferred for an https: URL.

I think all the problem you show are not related to updating from a zipped update site.

In any case, it's impossible to fix something if we can't reproduce the problem. So it's unlikely anyone can take action on this report unless you provide a series of steps that we can follow that will reproduce a problem. 😞

[andrew-tram]

I'm think I'm getting closer to isolating the issue...

Thanks for your fix you mentioned, @merks , will work on getting that into our product ASAP.

So, I rebuilt our product, stripped out all our in-house plugins and only keep Eclipse community stuff. Then tried to install the jazz.net Engineer Workflow Management update-site above (since it's free to download, just need a jazz.net account) and I get this screen...

Which is very strange because I've applied the patch in relation to #512. So I'm not sure why all these packages are trying to update.

As these are the only software sites available:

Unless this is causing it - eclipse-m2e/m2e-core#1751

[merks]

The m2e repository has many references:

Those in turn could also have references...

I think this system property can turn them off:

p2/bundles/org.eclipse.equinox.p2.engine/src/org/eclipse/equinox/p2/engine/ProvisioningContext.java

Lines 73 to 83 in ec65256

	/**
	* Instructs the provisioning context to follow metadata repository references when
	* providing queryables for obtaining metadata and artifacts. When this property is set to
	* "true", then metadata repository references that are encountered while loading the
	* specified metadata repositories will be included in the provisioning
	* context.
	*
	* @see #getMetadata(IProgressMonitor)
	* @see #setMetadataRepositories(URI[])
	*/
	public static final String FOLLOW_REPOSITORY_REFERENCES = "org.eclipse.equinox.p2.director.followRepositoryReferences"; //$NON-NLS-1$

[andrew-tram]

I've somewhat narrowed it down to one of our in-house plugins (I think) - still not sure what's causing it. Trying to do remote debugging with Equinox plugins.

Just came across this though, which seems similar - eclipse-platform/eclipse.platform#1561

They get the registry error when shutting down, whereas I get it when installing a package and I guess during the "restart" portion when installation is complete.

[andrew-tram]

It looks like the error gets thrown in org.eclipse.core.internal.registry.RegistryObjectManager....

	private Object basicGetObject(int id, byte type) {
		Object result = cache.get(id);
		if (result != null)
			return result;
		if (fromCache)
			result = load(id, type);
		if (result == null)
			throw new InvalidRegistryObjectException();
		cache.put(id, result);
		return result;
	}

I'm not 100% sure whats going on with the Debug trace, but I guess extensions are being removed? Or modified or updated or something?

Would that mean the in-house plugin's extension points are messing things up?

[andrew-tram]

Not sure why the values are different when going backwards in the trace...

Edit: Never mind

[andrew-tram]

Some more observations...

When installing a small and pretty self contained update site that has no extra dependencies that isn't already included in my base RCP application, it looks like some "selective" update is still happening when all I want to do is just install the self contained p2 repo.

I can't imagine why those few would update when the p2 repo that's set to install has do dependency on them nor does the repo package any of those bundles.

@merks , I know it'd be much easier if I could share plugins to reprod this, but I unfortunately can't do that as they are company assets. But if you have any suggestions or ideas I should try to isolate it, I'd appreciate it.

[andrew-tram]

As an experiment in org.eclipse.equinox.p2.artifact.repository.prefs and org.eclipse.equinox.p2.metadata.repository.prefs under
\myRCPapp\p2\org.eclipse.equinox.p2.engine.settings and
\myRCPapp\p2\org.eclipse.equinox.p2.engine\profileRegistry\DefaultProfile.profile.data.settings

I removed everything thats in the red box and the Install of my update-sites seem to go fine without issues

EDIT: Never mind, I dont know what happened.

[merks]

Please take this comment with a grain of salt, and don't read any insult. People who pay me to do things for them also get me to sign a nondisclosure agreement. I do a heck of a lot of things for free too, but my personal time is really very limited...

[andrew-tram]

I totally get it!

More notes for posterity: Product does use dropins to install a feature and plugin that contains some touchpoints.

# Ensuring p2 touchpoint plugin installed before this plugin
metaRequirements.0.namespace=org.eclipse.equinox.p2.iu
metaRequirements.0.name=com.ibm.xxx.touchpoint
metaRequirements.0.range=[7.2.0,8.0.0)

# Ensuring anther p2 touchpoint plugin installed before this plugin
metaRequirements.1.namespace=org.eclipse.equinox.p2.iu
metaRequirements.1.name=com.ibm.xxx.another.touchpoint
metaRequirements.1.range=[7.2.0,8.0.0)

# Ensuring necessary native fragments for p2 touchpoint installer before this plugin.
metaRequirements.2.matchExp= properties['some.native'] == 'win32'
metaRequirements.3.matchExp= properties['some.native'] == 'linux'
metaRequirements.4.matchExp= properties['some.native'] == 'aix'
metaRequirements.5.matchExp= properties['some.native'] == 'solaris'
metaRequirements.6.matchExp= properties['some.native'] == 'macosx'
metaRequirements.7.matchExp= properties['some.native'] == 'hpux'

# During configure phase,
#  1--> Set the p2 home dir if it does not exist during install phase of this plugin.
#  2--> Install something into p2 home dir.
instructions.configure = \
com.ibm.xxx.touchpoint.setp2home(); \
com.ibm.xxx.another.touchpoint.fileinstall(someFile:abc.txt);

The bug is encountered during software installation when the software requires touchpoint instructions and other meta-requirements that aren't part of the current installation. P2 attempts to pre-install these missing meta-requirements before proceeding with the actual installation. For touchpoint actions to be available, the platform configuration needs to change to activate bundles providing the new touchpoint actions. As a result, affected bundles may be stopped, uninstalled, installed, or rewired to meet the meta-requirements. The issue occurs when the actual installation happens during the meta-installation phase, causing numerous components to be stopped, rewired, and restarted.

This problem arises in the product due to its touchpoint mechanism introducing missing meta-requirements, triggering the pre-installation phase. Installing something that affects a low-level component, such as org.eclipse.ui.workbench, can lead to significant issues. It's unclear why this problem wasn't experienced before, as no significant changes have occurred since version 4.23.

[merks]

That’s super nice to share these insights and details. Indeed meta requirements are a big additional wrinkle that is little used by eclipse projects and hence not often exercised. Moreover it’s poorly understood at best so the people who can help support this are in short supply. They are eagerly pre-installed and started to complete the installation process.