[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857588#comment-16857588
]
Tilman Hausherr commented on NETBEANS-58:
-
I took the settings from my NB8 installation, so the start page wasn't shown.
But it frozed later, e.g. when searching for the latest plugins. Today I
managed to get it to work by using a local proxy that chains to my actual
proxy. That local proxy is a tool I've had for over a decade and I don't know
if I can install it on my next corporate pc.
So I tried again to install the two plugins but I can't, NB 11 still pops up a
dialog that requires "plugin Core" and "plugin JNA" and the "Next" button is
grey.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbA
[jira] [Comment Edited] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857532#comment-16857532
]
Tilman Hausherr edited comment on NETBEANS-771 at 6/6/19 11:03 AM:
---
I see that bug (failing to parse "0-SlikSvn") was likely fixed in NETBEANS-1936
one months ago.
was (Author: tilman):
I see that bug (failing to parse "0-SlikSvn") was likely fixed in NETBEANS-1936.
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857532#comment-16857532
]
Tilman Hausherr edited comment on NETBEANS-771 at 6/6/19 11:03 AM:
---
I see that bug (failing to parse "0-SlikSvn") was likely fixed in NETBEANS-1936
one month ago.
was (Author: tilman):
I see that bug (failing to parse "0-SlikSvn") was likely fixed in NETBEANS-1936
one months ago.
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857532#comment-16857532
]
Tilman Hausherr commented on NETBEANS-771:
--
I see that bug (failing to parse "0-SlikSvn") was likely fixed in NETBEANS-1936.
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856947#comment-16856947
]
Tilman Hausherr commented on NETBEANS-58:
-
NB 11 freezes at startup unless I disconnect the LAN cable, which is what also
happened with NB 8.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be needed when
> application is still not "warm", i.e. during startup.
> h3. WORKAROUNDS
> *#1*
> If on Windows: Sett
[jira] [Updated] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated NETBEANS-58:
Affects Version/s: 11.0
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be needed when
> application is still not "warm", i.e. during startup.
> h3. WORKAROUNDS
> *#1*
> If on Windows: Setting the following registry key:
> {{HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\allowtgtsessionkey}}
> to {{true
[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856596#comment-16856596
]
Tilman Hausherr commented on NETBEANS-58:
-
I just installed netbeans 11 because of NETBEANS-771. When trying to install
proxy selector v2, I get this message:
{quote}
h3. Some plugins require plugin Core to be installed.
The plugin Core is requested in implementation version 201609300101.
The following plugin is affected:
ProxySelector V2
h3. Some plugins require plugin JNA to be installed.
The plugin JNA is requested in implementation version 201609300101.
The following plugin is affected:
ProxySelector V2
{quote}
and I can't "check for updates" because proxy doesn't work. Where can I get
these plugins? A search on the plugin page finds me nothing.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be trig
[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856591#comment-16856591
]
Tilman Hausherr commented on NETBEANS-58:
-
[~phansson] There's a HTML problem in
http://plugins.netbeans.org/plugin/72976/
"You must have Proxy Selector V2 Plugin installed" links to
http://plugins.netbeans.org/plugin/72976/plugin/55258/
it should link to
http://plugins.netbeans.org/plugin/55258/proxyselector-v2
or
http://plugins.netbeans.org/plugin/55258/
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is actually virtually impossible to design an
> Authenticator which doesn't trigger
[jira] [Commented] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856586#comment-16856586
]
Tilman Hausherr commented on NETBEANS-771:
--
Reluctantly... I installed it (and temporarly disconnected the network cable
because of the problems in NETBEANS-58, I can't even install the plugins from
that issue, because the plugins need to go online to get "plugins core" and
going online freezes netbeans) and it doesn't work:
{noformat}
INFO [org.netbeans.modules.subversion]: Commandline client version:
1.12.0-SlikSvn (SlikSvn/1.12.0)
SEVERE [org.netbeans.modules.subversion]: For input string: "0-SlikSvn"
java.lang.NumberFormatException: For input string: "0-SlikSvn"
at
java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.base/java.lang.Integer.parseInt(Integer.java:652)
at java.base/java.lang.Integer.parseInt(Integer.java:770)
at
org.netbeans.modules.subversion.client.cli.commands.VersionCommand$Version.parse(VersionCommand.java:168)
at
org.netbeans.modules.subversion.client.cli.commands.VersionCommand$Version.parse(VersionCommand.java:146)
at
org.netbeans.modules.subversion.client.cli.commands.VersionCommand.checkForErrors(VersionCommand.java:87)
at
org.netbeans.modules.subversion.client.cli.CommandlineClient.checkSupportedVersion(CommandlineClient.java:132)
at
org.netbeans.modules.subversion.client.SvnClientFactory.checkVersion(SvnClientFactory.java:473)
at
org.netbeans.modules.subversion.client.SvnClientFactory.checkCLIExecutable(SvnClientFactory.java:430)
at
org.netbeans.modules.subversion.client.SvnClientFactory.setupCommandline(SvnClientFactory.java:403)
at
org.netbeans.modules.subversion.client.SvnClientFactory.setup(SvnClientFactory.java:222)
at
org.netbeans.modules.subversion.client.SvnClientFactory.init(SvnClientFactory.java:95)
at
org.netbeans.modules.subversion.client.SvnClientFactory.isClientAvailable(SvnClientFactory.java:240)
at
org.netbeans.modules.subversion.Annotator.checkClientAvailable(Annotator.java:638)
at
org.netbeans.modules.subversion.Annotator.annotateIcon(Annotator.java:506)
{noformat}
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
This message was sent by Atlassian JIRA
(v7.6
[jira] [Comment Edited] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856497#comment-16856497
]
Tilman Hausherr edited comment on NETBEANS-771 at 6/5/19 8:42 AM:
--
It's not fixed for 8.2, it happened to me with "8.2 patch 2" after I updated to
1.12.0 from [https://sliksvn.com/download/]
Never change a running system 😢
And per the first comment, this is a bug, not a wish.
was (Author: tilman):
It's not fixed for 8.2, it happened to me with "8.2 patch 2" after I updated to
1.12.0. https://sliksvn.com/download/
Never change a running system 😢
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated NETBEANS-771:
-
Issue Type: Bug (was: Wish)
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856497#comment-16856497
]
Tilman Hausherr commented on NETBEANS-771:
--
It's not fixed for 8.2, it happened to me with "8.2 patch 2" after I updated to
1.12.0. https://sliksvn.com/download/
Never change a running system 😢
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Wish
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated NETBEANS-771:
-
Affects Version/s: 8.2
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Wish
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16451760#comment-16451760
]
Tilman Hausherr commented on NETBEANS-58:
-
{quote}
It is super critical in a specific subset of scenarios, I for one have never
(working within and without a corporate proxy) have never encountered it, as
far as I am aware.
{quote}
[~GeertjanWielenga] have you ever worked with windows when within a corporate
proxy since jdk 1.8.25?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot
