Bug 548510 - Useless error message: org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry object
Summary: Useless error message: org.eclipse.core.runtime.InvalidRegistryObjectExceptio...
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Components (show other bugs)
Version: 4.12   Edit
Hardware: All All
: P3 normal with 1 vote (vote)
Target Milestone: 4.16 M1   Edit
Assignee: Eric Milles CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 540888 562561 (view as bug list)
Depends on: 540888
Blocks:
  Show dependency tree
 
Reported: 2019-06-21 07:21 EDT by Aaron Digulla CLA
Modified: 2020-04-28 16:11 EDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Digulla CLA 2019-06-21 07:21:19 EDT
When using the Groovy plugin, users can get these exceptions:

org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry object
	at org.eclipse.core.internal.registry.RegistryObjectManager.basicGetObject(RegistryObjectManager.java:277)
	at org.eclipse.core.internal.registry.RegistryObjectManager.getObject(RegistryObjectManager.java:267)
	at org.eclipse.core.internal.registry.ConfigurationElementHandle.getConfigurationElement(ConfigurationElementHandle.java:29)
	at org.eclipse.core.internal.registry.ConfigurationElementHandle.getChildren(ConfigurationElementHandle.java:53)
	at org.eclipse.core.internal.adapter.AdapterFactoryProxy.getAdapterNames(AdapterFactoryProxy.java:97)
	at org.eclipse.core.internal.runtime.AdapterManager.addFactoriesFor(AdapterManager.java:109)
	at org.eclipse.core.internal.runtime.AdapterManager.getFactories(AdapterManager.java:212)
	at org.eclipse.core.internal.runtime.AdapterManager.getAdapter(AdapterManager.java:295)
	at org.eclipse.core.runtime.PlatformObject.getAdapter(PlatformObject.java:72)
...

The exception gives no clue which object is wrong or why.

Please improve the error message so we're able to see which registry is invalid (it and type) plus chain the exception in org.eclipse.core.internal.runtime.AdapterManager.addFactoriesFor to get the typeName.
Comment 1 Eric Milles CLA 2019-06-21 11:53:57 EDT
This issue has a bit of a long history.  I wanted to include references in case anyone wanted to trace it.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=528462

https://github.com/spring-projects/spring-ide/issues/148
https://github.com/spring-projects/spring-ide/issues/151

https://github.com/groovy/groovy-eclipse/issues/309
https://github.com/groovy/groovy-eclipse/issues/317
https://github.com/groovy/groovy-eclipse/issues/555
https://github.com/groovy/groovy-eclipse/issues/590
https://github.com/groovy/groovy-eclipse/issues/620
https://github.com/groovy/groovy-eclipse/issues/681


Long story short: Groovy Development Tools include a bundle that starts very early and tries to enable only the user-selected version of the org.codehaus.groovyXY bundles.  If any GDT or JDT components have started before this, like say the Package Explorer or Java Editor, they may have already established references to the highest version bundle (default activated) and when this bundle is stopped, it is possible to get Invalid Registry Object errors.

Workaround available to user: uninstall versions of "Groovy Compile X.Y" feature that are not used.  If highest version available is the one in use, no switching is required.

Additional workaround: close all open editors and views that may try to reference Groovy features during IDE startup.  Mostly this means the Java and Groovy editors.
Comment 2 Andrey Loskutov CLA 2019-06-21 17:04:51 EDT
Sounds like a valid request. Do you want to contribute a patch?
Comment 3 Eric Milles CLA 2019-12-28 12:25:41 EST
How about this in org.eclipse.core.internal.adapter.AdapterFactoryProxy?

    @Override
    public String[] getAdapterNames() {
        /* was:
        IConfigurationElement[] children = element.getChildren();
        ArrayList<String> adapters = new ArrayList<>(children.length);
        for (IConfigurationElement child : children) {
            //ignore unknown children for forward compatibility
            if ("adapter".equals(child.getName())) {//$NON-NLS-1$
                String type = child.getAttribute("type"); //$NON-NLS-1$
                if (type != null)
                    adapters.add(type);
            }
        }
        if (adapters.isEmpty())
            logError();
        return adapters.toArray(new String[adapters.size()]);
        */
        try {
            String[] adapters = Arrays.stream(element.getChildren())
                // ignore unknown children for forward compatibility
                .filter(child -> "adapter".equals(child.getName())) //$NON-NLS-1$
                .map(child -> child.getAttribute("type")) //$NON-NLS-1$
                .filter(Objects::nonNull)
                .toArray(String[]::new);
            if (adapters.isEmpty()) {
                logError();
            }
            return adapters;
        } catch (InvalidRegistryObjectException e) {
            String msg = NLS.bind(RegistryMessages.adapters_cantInstansiate, getAdaptableType(), element.getContributor().getName());
            RuntimeLog.log(new Status(IStatus.ERROR, RegistryMessages.OWNER_NAME, 0, msg, e));
            return new String[0];
        }
    }


"element.getContributor().getName()" also indicates that it throws InvalidRegistryObjectException, so you may want to log more carefully.
Comment 4 Eric Milles CLA 2019-12-28 12:36:17 EST
I missed org.eclipse.core.runtime.IConfigurationElement#isValid().  I think the more general approach is to have any component that accesses an IConfigurationElement to check isValid() first and take appropriate steps if not valid.
Comment 5 Eric Milles CLA 2019-12-28 13:08:58 EST
    @Override
    public String[] getAdapterNames() {
        if (element.isValid()) {
            String[] adapters = Arrays.stream(element.getChildren())
                // ignore unknown children for forward compatibility
                .filter(child -> "adapter".equals(child.getName())) //$NON-NLS-1$
                .map(child -> child.getAttribute("type")) //$NON-NLS-1$
                .filter(Objects::nonNull)
                .toArray(String[]::new);
            if (adapters.isEmpty()) {
                logError();
            }
            return adapters;
        } else {
            String msg = NLS.bind(RegistryMessages.adapters_cantInstansiate, getAdaptableType(), "<unknown>");
            RuntimeLog.log(new Status(IStatus.ERROR, RegistryMessages.OWNER_NAME, 0, msg, e));
            return new String[0];
        }
    }
Comment 6 Andrey Loskutov CLA 2019-12-28 17:11:04 EST
Eric, please if you have an idea for the patch, use gerrit and not bugzilla.
Comment 7 Eclipse Genie CLA 2019-12-29 14:03:50 EST
New Gerrit change created: https://git.eclipse.org/r/155098
Comment 8 Aaron Digulla CLA 2019-12-30 07:13:45 EST
I left a few comments in the gerrit. Most are just minor but can you please include information which element is the problem?

Otherwise, we just get a log message "there was a problem" but no clue what it was.
Comment 9 Aaron Digulla CLA 2019-12-30 07:16:16 EST
I don't know much about IConfigurationElement. At least include name and namespace. I guess value is off limits when valid is false.
Comment 10 Andrey Loskutov CLA 2019-12-30 07:52:03 EST
(In reply to Aaron Digulla from comment #8)
> I left a few comments in the gerrit. Most are just minor but can you please
> include information which element is the problem?
> 
> Otherwise, we just get a log message "there was a problem" but no clue what
> it was.

Aaron, please *submit* your comments, otherwise others can't see them on Gerrit.
Comment 11 Aaron Digulla CLA 2019-12-30 09:23:08 EST
Thanks for the hint. Should be done now. I was very lost how to do that; the keyword was "Reply to make them visible" :-)
Comment 12 Eric Milles CLA 2020-01-09 15:47:35 EST
Okay, so I submitted a Gerrit change.  Any chance it makes it into Eclipse 2020-03 (4.15)?
Comment 13 Lars Vogel CLA 2020-04-06 06:44:10 EDT
Behavior looks good in the debugger to me, I merge this so that we can get it into our M1 testing.

Eric, thanks and sorry for the long delay in review time. Please test with tomorrows I-build and watch https://download.eclipse.org/eclipse/downloads/ the latest I-Build for new test errors related to this change.
Comment 14 Lars Vogel CLA 2020-04-06 06:45:08 EDT
*** Bug 540888 has been marked as a duplicate of this bug. ***
Comment 15 Eric Milles CLA 2020-04-09 10:48:48 EDT
Bug 542086 also looks related.
Comment 16 Eric Milles CLA 2020-04-09 10:49:23 EDT
Bug 542086 also looks related.
Comment 17 Stephan Herrmann CLA 2020-04-28 16:11:11 EDT
*** Bug 562561 has been marked as a duplicate of this bug. ***