Re: [platform-dev] Link Handler Auto Registration?

[Mickael Istria]

Hi,

On Thu, Jul 2, 2020 at 9:05 AM Ed Merks  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
> /.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,
>
> Collection)
>
>  @Override
>  public void handleSchemes(Collection toAdd,
> Collection 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
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Link Handler Auto Registration?

[Ed Merks]

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 
/.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, 
Collection)


    @Override
    public void handleSchemes(Collection toAdd, 
Collection 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
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev