Link Handler Auto Registration?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Link Handler Auto Registration?

Ed Merks-2
There has been quite some activity around auto registering link
handlers.   For whatever reason that's not clear to me, in my Oomph
development environment, the method
org.eclipse.urischeme.internal.registration.RegistrationWindows.getEclipseLauncher()
returns null.  In the end, that's because
<workspace>/.metadata/.plugins/org.eclipse.pde.core/.install_folders/1592731586281
does not contain a *.exe.  In my Platform SDK environment there is an
eclipsec.exe in that analogous folder when I do a self-hosted launch. In
any case, a null launcher subsequently causes this exception on every
self-hosted launch:

java.lang.NullPointerException
     at com.sun.jna.Native.toCharArray(Native.java:824)
     at
com.sun.jna.platform.win32.Advapi32Util.registrySetStringValue(Advapi32Util.java:1233)
     at
com.sun.jna.platform.win32.Advapi32Util.registrySetStringValue(Advapi32Util.java:1262)
     at
org.eclipse.urischeme.internal.registration.WinRegistry.setValueForKey(WinRegistry.java:33)
     at
org.eclipse.urischeme.internal.registration.RegistryWriter.addScheme(RegistryWriter.java:60)
     at
org.eclipse.urischeme.internal.registration.RegistrationWindows.handleSchemes(RegistrationWindows.java:61)
     at
org.eclipse.urischeme.AutoRegisterSchemeHandlersJob.run(AutoRegisterSchemeHandlersJob.java:70)
     at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

That could be avoided by checking for null like this in
org.eclipse.urischeme.internal.registration.RegistrationWindows.handleSchemes(Collection<IScheme>,
Collection<IScheme>)

     @Override
     public void handleSchemes(Collection<IScheme> toAdd,
Collection<IScheme> toRemove)
             throws Exception {
         String eclipseLauncher = getEclipseLauncher();
         if (eclipseLauncher != null) {
             for (IScheme scheme : toAdd) {
                 registryWriter.addScheme(scheme.getName(),
eclipseLauncher);
             }
         }

But the more fundamental question is, what is the desired/intended
behavior of org.eclipse.urischeme.AutoRegisterSchemeHandlersJob?   It
appears the actual behavior is that each IDE that's launched forcibly
takes the registration, replacing any existing registration. Perhaps
that's fine and good and is the intent, though when one has 10 Eclipse
applications running like I do, it's a little questionable.  But note
that in the case that a self-hosted launch happens to find a *.exe in
.install_folders (avoiding an NPE error), this also implies that the
self-hosted launched IDE forcibly takes over the registration such that
the original host IDE itself is no longer registered.  Surely that is
not the intent of the design is it?

Regards,
Ed



_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Link Handler Auto Registration?

Mickael Istria-5
Hi,

On Thu, Jul 2, 2020 at 9:05 AM Ed Merks <[hidden email]> wrote:
There has been quite some activity around auto registering link
handlers.   For whatever reason that's not clear to me, in my Oomph
development environment, the method
org.eclipse.urischeme.internal.registration.RegistrationWindows.getEclipseLauncher()
returns null.  In the end, that's because
<workspace>/.metadata/.plugins/org.eclipse.pde.core/.install_folders/1592731586281
does not contain a *.exe.  In my Platform SDK environment there is an
eclipsec.exe in that analogous folder when I do a self-hosted launch. In
any case, a null launcher subsequently causes this exception on every
self-hosted launch:

java.lang.NullPointerException
     at com.sun.jna.Native.toCharArray(Native.java:824)
     at
com.sun.jna.platform.win32.Advapi32Util.registrySetStringValue(Advapi32Util.java:1233)
     at
com.sun.jna.platform.win32.Advapi32Util.registrySetStringValue(Advapi32Util.java:1262)
     at
org.eclipse.urischeme.internal.registration.WinRegistry.setValueForKey(WinRegistry.java:33)
     at
org.eclipse.urischeme.internal.registration.RegistryWriter.addScheme(RegistryWriter.java:60)
     at
org.eclipse.urischeme.internal.registration.RegistrationWindows.handleSchemes(RegistrationWindows.java:61)
     at
org.eclipse.urischeme.AutoRegisterSchemeHandlersJob.run(AutoRegisterSchemeHandlersJob.java:70)
     at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

That could be avoided by checking for null like this in
org.eclipse.urischeme.internal.registration.RegistrationWindows.handleSchemes(Collection<IScheme>,
Collection<IScheme>)

     @Override
     public void handleSchemes(Collection<IScheme> toAdd,
Collection<IScheme> toRemove)
             throws Exception {
         String eclipseLauncher = getEclipseLauncher();
         if (eclipseLauncher != null) {
             for (IScheme scheme : toAdd) {
                 registryWriter.addScheme(scheme.getName(),
eclipseLauncher);
             }
         }

Please report a bug about it, and add Matthias (Becker) as CC as I believe he's the one who's most able to fix it.

But the more fundamental question is, what is the desired/intended
behavior of org.eclipse.urischeme.AutoRegisterSchemeHandlersJob?   It
appears the actual behavior is that each IDE that's launched forcibly
takes the registration, replacing any existing registration.

That's not what's intended. See https://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org.eclipse.urischeme/src/org/eclipse/urischeme/AutoRegisterSchemeHandlersJob.java#n65 , already handled schemes are filtered out of processing. Only schemes that are currently not handled by the OS and are known to the Eclipse Link handler will be tentatively assigned to the current IDE. Other ones should remain unchanged.
If it behaves differently, then it's a bug, and if you open it, please add me as CC as well.

Cheers

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev