[jira] [Commented] (NETBEANS-2842) Using of deprecated pack200 tool in nbm packaging
[ https://issues.apache.org/jira/browse/NETBEANS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770143#comment-17770143 ] Jean-Marc Borer commented on NETBEANS-2842: --- When building NB applications with the nbm-maven-plugin and Maven, how do we know if Pack200 is used or not? > Using of deprecated pack200 tool in nbm packaging > - > > Key: NETBEANS-2842 > URL: https://issues.apache.org/jira/browse/NETBEANS-2842 > Project: NetBeans > Issue Type: Bug > Components: platform - Plugin Manager >Affects Versions: 11.3 >Reporter: Benjamin Graf >Priority: Critical > Attachments: nbpython.zip, unpack200 failure.png > > > Netbeans plugins are mostly compressed in size by the JDK internal pack200 > tool which is deprecated since JDK 11 ([https://openjdk.java.net/jeps/336]). > It should be thought about an alternative as it might get removed in next JDK > releases. -- This message was sent by Atlassian Jira (v8.20.10#820010) - 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-5292) nb-javac is source of several issues
[ https://issues.apache.org/jira/browse/NETBEANS-5292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485613#comment-17485613 ] Jean-Marc Borer commented on NETBEANS-5292: --- [~taps] Ok, but then it should be clearly stated. It is not according to https://netbeans.apache.org/download/nb126/nb126.html > nb-javac is source of several issues > > > Key: NETBEANS-5292 > URL: https://issues.apache.org/jira/browse/NETBEANS-5292 > Project: NetBeans > Issue Type: Bug > Components: java - Compiler, java - Editor, java - Hints, platform - > Action Items >Affects Versions: 11.3, 12.2, 12.4 > Environment: Gradle 6.8.1 > Possibly any JDK version 11 > nb-javac installed >Reporter: Netbeans User 2019 >Priority: Critical > Labels: hints, nbjavac, nbjavac-impl.jar > > There are several issue reporting NullPointerException and in logs even > several related to hints (In context of Tools > Options > Editor > Hints). > So my suggestions are: > 1) to be deactivated all hints and retested with and with and without > nb-javac as seems that many issue like this is connected nb-javac, but It > could be even possible that hints are not revised at all from start and even > it is possible that could be ticked to run by import from prior version of > Netbeans, but it could be unsupported in new version. > 2) turn off of nb-javac does not fix issues like these, because it seems that > that states is ignored and nb-javac is still somehow in use ... so only > option is to uninstalled completely (so to see in notification request for > installation) - so it has to be fixed that if it is inactivated should not be > used > 3) to be added even new feature to reset all Hints to default > 4) seems that even some of such failure (even reported as race condition) > that leads to cases that it is not finished indexing so particular classes > are not index so even not visible by dialog to of types and in java editor is > represented as errors and there is not way to removed that reds, because > there are no way to tell to Apache Netbeans that such class is existing and > it is correct. > 5) "Background scanning of projects..." is even running for minutes with > nb-javac installed > Even if it is not done in minor version I would like to see it in major > version fixed. > To me it seems that nb-javac brings more issue than save -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-2617) Redraw common icons in SVG
[
https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478716#comment-17478716
]
Jean-Marc Borer edited comment on NETBEANS-2617 at 1/19/22, 2:41 PM:
-
An viable alternative to AI and Inkscape (much cheaper one actually) is
Affinity Designer. As capable to AI. Can read and export for AI. It has as well
very powerful export (slice) and preview features.
Here the template:
!image-2022-01-19-14-41-29-967.png!
May I suggest to provide a color palette as well for the icons to remain
consistent?
I agree that flat design is much better. However too flat is not so nice as
well. I think an intermediate would be a nice material design: flat and simple,
but with a slight touch of gradients.
[https://material.io/design/material-theming/overview.html#material-theming]
was (Author: jmborer):
An viable alternative to AI and Inkscape (much cheaper one actually) is
Affinity Designer. As capable to AI. Can read and export for AI. It has as well
very powerful export (slice) and preview features.
May I suggest to provide a color palette as well for the icons to remain
consistent?
I agree that flat design is much better. However too flat is not so nice as
well. I think an intermediate would be a nice material design: flat and simple,
but with a slight touch of gradients.
https://material.io/design/material-theming/overview.html#material-theming
> Redraw common icons in SVG
> --
>
> Key: NETBEANS-2617
> URL: https://issues.apache.org/jira/browse/NETBEANS-2617
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Other
>Affects Versions: 11.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
> Labels: HiDPI
> Attachments: 210604 Icons Overview Cropped.png, 211228 Consolidated
> Icons.ai, 220101 Updated Dark Filter Test.png, ScreenshotExample.png,
> ide.editor.bookmarks.ai, ide.editor.macros.ai, ide.seperator.breadcrumbs.ai,
> image-2022-01-19-14-41-29-967.png, netbeans_icons_illustrator_template.ai,
> style example (dark filter).png, style example.png
>
>
> Once NETBEANS-2604 is done, we should start replacing commonly seen NetBeans
> icons with SVG versions, for improved appearance on Retina/HiDPI displays.
> h2. UPDATE:
> [Here|https://docs.google.com/spreadsheets/d/1U_pj-I3hk9Wj_7lvHcUDsZfFfBSyCkSGqBuv0qt_qXw/edit?usp=sharing]
> is a Google Sheet where we can track progress of contributions and
> prioritization of icons.
> With some practice, it takes on average 30 minutes to create an SVG version
> of a typical icon in Adobe Illustrator. See the attached illustration and
> Illustrator template. The Illustrator template includes a few icons which
> have already been converted.
> In NETBEANS-2605, a prioritized list of icons to convert was produced (now
> migrated to the Google Sheet above). By redrawing the most commonly seen
> icons first, we can get the greatest "bang for the buck" in terms of
> improving NetBeans' appearance on HiDPI displays. Once we have a batch of
> icons ready to integrate into the NetBeans repository, Eirik will redo the
> duplicate detection and ensure the SVGs end up in all relevant locations, and
> start creating pull requests.
> See also the overview page for HiDPI improvements on
> https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements
> .
> If you wish to contribute to this effort, comment here; Eirik will coordinate
> to make sure multiple people are not working on the same icons.
> h2. Proposed Style Guide for Vectorized Icons
> * Vector icons should be drawn in Adobe Illustrator, or alternatively
> Inkscape or another free tool. In Illustrator, each icon should be one named
> artboard, sized to the correct size in pixels. See the attached Illustrator
> template. (Adobe Illustrator comes with a free 7-day trial, after which it's
> $35/month. If cost is a problem but you want to contribute your time to draw
> icons, ask Eirik...)
> * If you prefer to use Inkscape instead, and want to contribute icons, that's
> fine; just make sure to follow the same consistent style as the other icons.
> If using Inkscape, perhaps pick another group of icons than the ones that are
> currently being drawn in Illustrator. It's best to draw all similar-looking
> icons in the same tool.
> * For each icon to be vectorized, place the old bitmap version of the icon in
> a separate layer ("Old Bitmap Icons" in the Illustrator template). You can
> then draw the vectorized version on top.
> * Since most of the existing NetBeans icons follow a quite consistent visual
> style, and to simplify the job of creating new icons, it is best to keep the
> shape of the new vectorized icons the same as in the
[jira] [Comment Edited] (NETBEANS-2617) Redraw common icons in SVG
[
https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478716#comment-17478716
]
Jean-Marc Borer edited comment on NETBEANS-2617 at 1/19/22, 2:36 PM:
-
An viable alternative to AI and Inkscape (much cheaper one actually) is
Affinity Designer. As capable to AI. Can read and export for AI. It has as well
very powerful export (slice) and preview features.
May I suggest to provide a color palette as well for the icons to remain
consistent?
I agree that flat design is much better. However too flat is not so nice as
well. I think an intermediate would be a nice material design: flat and simple,
but with a slight touch of gradients.
https://material.io/design/material-theming/overview.html#material-theming
was (Author: jmborer):
An viable alternative to AI and Inkscape (much cheaper one actually) is
Affinity Designer. As capable to AI. Can read and export for AI. It has as well
very powerful export (slice) and preview features.
> Redraw common icons in SVG
> --
>
> Key: NETBEANS-2617
> URL: https://issues.apache.org/jira/browse/NETBEANS-2617
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Other
>Affects Versions: 11.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
> Labels: HiDPI
> Attachments: 210604 Icons Overview Cropped.png, 211228 Consolidated
> Icons.ai, 220101 Updated Dark Filter Test.png, ScreenshotExample.png,
> ide.editor.bookmarks.ai, ide.editor.macros.ai, ide.seperator.breadcrumbs.ai,
> netbeans_icons_illustrator_template.ai, style example (dark filter).png,
> style example.png
>
>
> Once NETBEANS-2604 is done, we should start replacing commonly seen NetBeans
> icons with SVG versions, for improved appearance on Retina/HiDPI displays.
> h2. UPDATE:
> [Here|https://docs.google.com/spreadsheets/d/1U_pj-I3hk9Wj_7lvHcUDsZfFfBSyCkSGqBuv0qt_qXw/edit?usp=sharing]
> is a Google Sheet where we can track progress of contributions and
> prioritization of icons.
> With some practice, it takes on average 30 minutes to create an SVG version
> of a typical icon in Adobe Illustrator. See the attached illustration and
> Illustrator template. The Illustrator template includes a few icons which
> have already been converted.
> In NETBEANS-2605, a prioritized list of icons to convert was produced (now
> migrated to the Google Sheet above). By redrawing the most commonly seen
> icons first, we can get the greatest "bang for the buck" in terms of
> improving NetBeans' appearance on HiDPI displays. Once we have a batch of
> icons ready to integrate into the NetBeans repository, Eirik will redo the
> duplicate detection and ensure the SVGs end up in all relevant locations, and
> start creating pull requests.
> See also the overview page for HiDPI improvements on
> https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements
> .
> If you wish to contribute to this effort, comment here; Eirik will coordinate
> to make sure multiple people are not working on the same icons.
> h2. Proposed Style Guide for Vectorized Icons
> * Vector icons should be drawn in Adobe Illustrator, or alternatively
> Inkscape or another free tool. In Illustrator, each icon should be one named
> artboard, sized to the correct size in pixels. See the attached Illustrator
> template. (Adobe Illustrator comes with a free 7-day trial, after which it's
> $35/month. If cost is a problem but you want to contribute your time to draw
> icons, ask Eirik...)
> * If you prefer to use Inkscape instead, and want to contribute icons, that's
> fine; just make sure to follow the same consistent style as the other icons.
> If using Inkscape, perhaps pick another group of icons than the ones that are
> currently being drawn in Illustrator. It's best to draw all similar-looking
> icons in the same tool.
> * For each icon to be vectorized, place the old bitmap version of the icon in
> a separate layer ("Old Bitmap Icons" in the Illustrator template). You can
> then draw the vectorized version on top.
> * Since most of the existing NetBeans icons follow a quite consistent visual
> style, and to simplify the job of creating new icons, it is best to keep the
> shape of the new vectorized icons the same as in the old bitmap icons. For
> instance, a rectangle of size 5x4px in the bitmap icon should probably become
> a rectangle of 5x4px in the vector version.
> * Keep the same general colors in vectorized icons as in the corresponding
> old bitmap icons.
> * Some of the old bitmap icons use grays with a slightly blue tint (e.g. the
> [file
>
[jira] [Commented] (NETBEANS-2617) Redraw common icons in SVG
[
https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478716#comment-17478716
]
Jean-Marc Borer commented on NETBEANS-2617:
---
An viable alternative to AI and Inkscape (much cheaper one actually) is
Affinity Designer. As capable to AI. Can read and export for AI. It has as well
very powerful export (slice) and preview features.
> Redraw common icons in SVG
> --
>
> Key: NETBEANS-2617
> URL: https://issues.apache.org/jira/browse/NETBEANS-2617
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Other
>Affects Versions: 11.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
> Labels: HiDPI
> Attachments: 210604 Icons Overview Cropped.png, 211228 Consolidated
> Icons.ai, 220101 Updated Dark Filter Test.png, ScreenshotExample.png,
> ide.editor.bookmarks.ai, ide.editor.macros.ai, ide.seperator.breadcrumbs.ai,
> netbeans_icons_illustrator_template.ai, style example (dark filter).png,
> style example.png
>
>
> Once NETBEANS-2604 is done, we should start replacing commonly seen NetBeans
> icons with SVG versions, for improved appearance on Retina/HiDPI displays.
> h2. UPDATE:
> [Here|https://docs.google.com/spreadsheets/d/1U_pj-I3hk9Wj_7lvHcUDsZfFfBSyCkSGqBuv0qt_qXw/edit?usp=sharing]
> is a Google Sheet where we can track progress of contributions and
> prioritization of icons.
> With some practice, it takes on average 30 minutes to create an SVG version
> of a typical icon in Adobe Illustrator. See the attached illustration and
> Illustrator template. The Illustrator template includes a few icons which
> have already been converted.
> In NETBEANS-2605, a prioritized list of icons to convert was produced (now
> migrated to the Google Sheet above). By redrawing the most commonly seen
> icons first, we can get the greatest "bang for the buck" in terms of
> improving NetBeans' appearance on HiDPI displays. Once we have a batch of
> icons ready to integrate into the NetBeans repository, Eirik will redo the
> duplicate detection and ensure the SVGs end up in all relevant locations, and
> start creating pull requests.
> See also the overview page for HiDPI improvements on
> https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements
> .
> If you wish to contribute to this effort, comment here; Eirik will coordinate
> to make sure multiple people are not working on the same icons.
> h2. Proposed Style Guide for Vectorized Icons
> * Vector icons should be drawn in Adobe Illustrator, or alternatively
> Inkscape or another free tool. In Illustrator, each icon should be one named
> artboard, sized to the correct size in pixels. See the attached Illustrator
> template. (Adobe Illustrator comes with a free 7-day trial, after which it's
> $35/month. If cost is a problem but you want to contribute your time to draw
> icons, ask Eirik...)
> * If you prefer to use Inkscape instead, and want to contribute icons, that's
> fine; just make sure to follow the same consistent style as the other icons.
> If using Inkscape, perhaps pick another group of icons than the ones that are
> currently being drawn in Illustrator. It's best to draw all similar-looking
> icons in the same tool.
> * For each icon to be vectorized, place the old bitmap version of the icon in
> a separate layer ("Old Bitmap Icons" in the Illustrator template). You can
> then draw the vectorized version on top.
> * Since most of the existing NetBeans icons follow a quite consistent visual
> style, and to simplify the job of creating new icons, it is best to keep the
> shape of the new vectorized icons the same as in the old bitmap icons. For
> instance, a rectangle of size 5x4px in the bitmap icon should probably become
> a rectangle of 5x4px in the vector version.
> * Keep the same general colors in vectorized icons as in the corresponding
> old bitmap icons.
> * Some of the old bitmap icons use grays with a slightly blue tint (e.g. the
> [file
> icons|https://raw.githubusercontent.com/apache/netbeans/master/java/refactoring.java/src/org/netbeans/modules/refactoring/java/resources/newFile.png]).
> This style is out of fashion (resembling 1990s Solaris GUIs etc.); use
> neutral greys instead.
> * If the old bitmap icon is complex, it is fine to simplify it a bit when
> drawing vectorized versions.
> * Omit gradients, bevels, and unnecessary drop shadows. They take more time
> to draw, and with "flat design", they are now out of fashion in any case.
> * Use a stroke width of 1px around the main shapes in the icon, like in the
> existing bitmap icons. The new icons should look consistent with the existing
> bitmap icons, especially since we may see bitmap icons and vector icons
>
[jira] [Updated] (NETBEANS-6390) Netbeans Apache web site (especially the documentation part) is seriously broken
[ https://issues.apache.org/jira/browse/NETBEANS-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer updated NETBEANS-6390: -- Summary: Netbeans Apache web site (especially the documentation part) is seriously broken (was: Apache web site (especially the docuementation part) is seriously broken) > Netbeans Apache web site (especially the documentation part) is seriously > broken > > > Key: NETBEANS-6390 > URL: https://issues.apache.org/jira/browse/NETBEANS-6390 > Project: NetBeans > Issue Type: Bug > Components: website >Reporter: Jean-Marc Borer >Priority: Major > > While looking for documentation, I was browsing the apache web site and it > seems seriously broken. When I follow the pages from > [https://netbeans.apache.org/] I get: > [https://netbeans.apache.org/kb/docs/platform.html] > where a lot of links are broken. Even the images. > > When I find a page through google I get: > [https://netbeans.apache.org/kb/docs/platform/] > the page is fine!! > > Notice the difference? Currently the site is not properly browesable. Only > google allows you to find the proper pages, if you know what you are looking > for... > > The broken version has as well links with http instead of https (look for the > netbeans platform faq on the page above). > > The links to the previously package info are broken as well... > -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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] [Created] (NETBEANS-6390) Apache web site (especially the docuementation part) is seriously broken
Jean-Marc Borer created NETBEANS-6390: - Summary: Apache web site (especially the docuementation part) is seriously broken Key: NETBEANS-6390 URL: https://issues.apache.org/jira/browse/NETBEANS-6390 Project: NetBeans Issue Type: Bug Components: website Reporter: Jean-Marc Borer While looking for documentation, I was browsing the apache web site and it seems seriously broken. When I follow the pages from [https://netbeans.apache.org/] I get: [https://netbeans.apache.org/kb/docs/platform.html] where a lot of links are broken. Even the images. When I find a page through google I get: [https://netbeans.apache.org/kb/docs/platform/] the page is fine!! Notice the difference? Currently the site is not properly browesable. Only google allows you to find the proper pages, if you know what you are looking for... The broken version has as well links with http instead of https (look for the netbeans platform faq on the page above). The links to the previously package info are broken as well... -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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] [Created] (NETBEANSINFRA-262) Class-Path manifest entry not properly URL decoded
Jean-Marc Borer created NETBEANSINFRA-262:
-
Summary: Class-Path manifest entry not properly URL decoded
Key: NETBEANSINFRA-262
URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-262
Project: Apache NetBeans Infra
Issue Type: Bug
Components: MU - Apache NetBeans NBM maven plugin
Affects Versions: NBM Maven Plugin 4.6
Reporter: Jean-Marc Borer
Compilation of NB RCP apps lead to
Could not resolve Class-Path item in
org.netbeans.api:org-netbeans-libs-javafx:nbm-file:RELEASE124, path
is:%24%7Bjava.home%7D/lib/ext/jfxrt.jar, skipping
since the commit that changes this is here:
[https://github.com/apache/netbeans/commit/1b96b56ac3bfda8bd9b97f36c25901e84289cb23]
And is part of this:
[https://github.com/apache/netbeans/pull/2761]
${java.home} is now URL encoded in the manifest. According to
[https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath]
Every Class-Path are URLs and as such should be decoded accordingly and
therefore the class CreateClusterAppMojo should be fixed:
lines 376 shall become:
try
{
classPath = URLDecoder.decode(ex.getClasspath(), "UTF-8");
} catch (UnsupportedEncodingException exception)
{
throw new IllegalStateException(exception);
}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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-6360) NB platform processes not seen as closed by NB IDE
[ https://issues.apache.org/jira/browse/NETBEANS-6360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475426#comment-17475426 ] Jean-Marc Borer edited comment on NETBEANS-6360 at 1/13/22, 3:00 PM: - Hello. Same behaviour with NB 12.6 and JDK 15. The application is launched via Maven and on a JDK8. was (Author: jmborer): Hello. Same behaviour with NB 12.6 and JDK 15. The application is launch via Maven and on a JDK8. > NB platform processes not seen as closed by NB IDE > -- > > Key: NETBEANS-6360 > URL: https://issues.apache.org/jira/browse/NETBEANS-6360 > Project: NetBeans > Issue Type: Bug > Components: platform - Execution >Affects Versions: 12.4, 12.5 > Environment: *Product Version:* Apache NetBeans IDE 12.5 > *Java:* 1.8.0_312; OpenJDK 64-Bit Server VM 25.312-b07 > *Runtime:* OpenJDK Runtime Environment 1.8.0_312-b07 > *System:* Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb) > *User directory:* C:\Users\borerjc\AppData\Roaming\NetBeans\12.5 > *Cache directory:* C:\Users\borerjc\AppData\Local\NetBeans\Cache\12.5 >Reporter: Jean-Marc Borer >Priority: Minor > Attachments: 2022-01-04 11_30_34-crystal-position-rosterplus-app - > 6.6.2-SNAPSHOT - PJ09_44 - Apache NetBeans IDE.png > > > When running NB applications from within NB IDE, on IDE close, it reports > that the processes are still running even though the application have been > properly stopped. > The IDE eventually exits, but it takes more time than necessary. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-6360) NB platform processes not seen as closed by NB IDE
[ https://issues.apache.org/jira/browse/NETBEANS-6360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475426#comment-17475426 ] Jean-Marc Borer commented on NETBEANS-6360: --- Hello. Same behaviour with NB 12.6 and JDK 15. The application is launch via Maven and on a JDK8. > NB platform processes not seen as closed by NB IDE > -- > > Key: NETBEANS-6360 > URL: https://issues.apache.org/jira/browse/NETBEANS-6360 > Project: NetBeans > Issue Type: Bug > Components: platform - Execution >Affects Versions: 12.4, 12.5 > Environment: *Product Version:* Apache NetBeans IDE 12.5 > *Java:* 1.8.0_312; OpenJDK 64-Bit Server VM 25.312-b07 > *Runtime:* OpenJDK Runtime Environment 1.8.0_312-b07 > *System:* Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb) > *User directory:* C:\Users\borerjc\AppData\Roaming\NetBeans\12.5 > *Cache directory:* C:\Users\borerjc\AppData\Local\NetBeans\Cache\12.5 >Reporter: Jean-Marc Borer >Priority: Minor > Attachments: 2022-01-04 11_30_34-crystal-position-rosterplus-app - > 6.6.2-SNAPSHOT - PJ09_44 - Apache NetBeans IDE.png > > > When running NB applications from within NB IDE, on IDE close, it reports > that the processes are still running even though the application have been > properly stopped. > The IDE eventually exits, but it takes more time than necessary. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-6386) Netbeans JavaDoc site is not properly generated
[ https://issues.apache.org/jira/browse/NETBEANS-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer updated NETBEANS-6386: -- Description: I have noticed that many pages with important documentation are missing on the official web site. For example, on page [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/package-summary.html#package.description] there are links to [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/doc-files/api.html] [https://bits.netbeans.org/12.6/javadoc/org-netbeans-modules-editor-indent/overview-summary.html] Those pages are missing. They exist in the sources. This is particularly annoying to find information and the documentation is hardly useful in these conditions. was: I have noticed that many pages with important documentation are missing on the official web site. For example, on page [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/package-summary.html#package.description] there are links to [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/doc-files/api.html] [https://bits.netbeans.org/12.6/javadoc/org-netbeans-modules-editor-indent/overview-summary.html] Those pages are missing. They exist in the sources. This is particularly annoying to find information. > Netbeans JavaDoc site is not properly generated > --- > > Key: NETBEANS-6386 > URL: https://issues.apache.org/jira/browse/NETBEANS-6386 > Project: NetBeans > Issue Type: Bug > Components: website >Reporter: Jean-Marc Borer >Priority: Major > > I have noticed that many pages with important documentation are missing on > the official web site. > For example, on page > [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/package-summary.html#package.description] > there are links to > [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/doc-files/api.html] > [https://bits.netbeans.org/12.6/javadoc/org-netbeans-modules-editor-indent/overview-summary.html] > Those pages are missing. They exist in the sources. > This is particularly annoying to find information and the documentation is > hardly useful in these conditions. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-6386) Netbeans JavaDoc site is not properly generated
[ https://issues.apache.org/jira/browse/NETBEANS-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer updated NETBEANS-6386: -- Description: I have noticed that many pages with important documentation are missing on the official web site. For example, on page [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/package-summary.html#package.description] there are links to [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/doc-files/api.html] [https://bits.netbeans.org/12.6/javadoc/org-netbeans-modules-editor-indent/overview-summary.html] Those pages are missing. They exist in the sources. This is particularly annoying to find information. was: I have noticed that many pages with important documentation are missing on the official web site. For example: [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/doc-files/api.html] This is particularly annoying to find information. > Netbeans JavaDoc site is not properly generated > --- > > Key: NETBEANS-6386 > URL: https://issues.apache.org/jira/browse/NETBEANS-6386 > Project: NetBeans > Issue Type: Bug > Components: website >Reporter: Jean-Marc Borer >Priority: Major > > I have noticed that many pages with important documentation are missing on > the official web site. > For example, on page > [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/package-summary.html#package.description] > there are links to > [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/doc-files/api.html] > [https://bits.netbeans.org/12.6/javadoc/org-netbeans-modules-editor-indent/overview-summary.html] > Those pages are missing. They exist in the sources. > This is particularly annoying to find information. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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] [Created] (NETBEANS-6386) Netbeans JavaDoc site is not properly generated
Jean-Marc Borer created NETBEANS-6386: - Summary: Netbeans JavaDoc site is not properly generated Key: NETBEANS-6386 URL: https://issues.apache.org/jira/browse/NETBEANS-6386 Project: NetBeans Issue Type: Bug Components: website Reporter: Jean-Marc Borer I have noticed that many pages with important documentation are missing on the official web site. For example: [https://bits.netbeans.org/12.6/javadoc/org-openide-text/org/openide/text/doc-files/api.html] This is particularly annoying to find information. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-6285) Netbeans 12.6 seems no properly run on JDK 8
[ https://issues.apache.org/jira/browse/NETBEANS-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469086#comment-17469086 ] Jean-Marc Borer commented on NETBEANS-6285: --- [~neilcsmith] another option could be to release the maven dependencies with _jdk8_ qualifier as well. > Netbeans 12.6 seems no properly run on JDK 8 > > > Key: NETBEANS-6285 > URL: https://issues.apache.org/jira/browse/NETBEANS-6285 > Project: NetBeans > Issue Type: Bug > Components: java - Platform >Affects Versions: 12.6 >Reporter: Jean-Marc Borer >Priority: Major > Attachments: messages.log > > > After a full fresh install of NB12.6 and trying to run with Azul Open JDK 1.8 > 312, there are several ClassNotFoundExceptions in the logs. It seems that NB > looks for missing methods that make NB not longer properly. For example, it > is no longer possible to properly format Java sources files due to a > java/nio/CharBuffer method missing. > Is NB platform supposed to no longer work with Java 8? -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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] [Created] (NETBEANS-6360) NB platform processes not seen as closed by NB IDE
Jean-Marc Borer created NETBEANS-6360: - Summary: NB platform processes not seen as closed by NB IDE Key: NETBEANS-6360 URL: https://issues.apache.org/jira/browse/NETBEANS-6360 Project: NetBeans Issue Type: Bug Components: platform - Execution Affects Versions: 12.5, 12.4 Environment: *Product Version:* Apache NetBeans IDE 12.5 *Java:* 1.8.0_312; OpenJDK 64-Bit Server VM 25.312-b07 *Runtime:* OpenJDK Runtime Environment 1.8.0_312-b07 *System:* Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb) *User directory:* C:\Users\borerjc\AppData\Roaming\NetBeans\12.5 *Cache directory:* C:\Users\borerjc\AppData\Local\NetBeans\Cache\12.5 Reporter: Jean-Marc Borer Attachments: 2022-01-04 11_30_34-crystal-position-rosterplus-app - 6.6.2-SNAPSHOT - PJ09_44 - Apache NetBeans IDE.png When running NB applications from within NB IDE, on IDE close, it reports that the processes are still running even though the application have been properly stopped. The IDE eventually exits, but it takes more time than necessary. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-6285) Netbeans 12.6 seems no properly run on JDK 8
[ https://issues.apache.org/jira/browse/NETBEANS-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468395#comment-17468395 ] Jean-Marc Borer edited comment on NETBEANS-6285 at 1/4/22, 7:06 AM: Remember that it is not only the IDE that is impacted. We have several NB platform apps, that we upgrade on a regular base and still have to use Java 8. It means that we cannot use any version after 12.5 without upgrading to JDK 9+. This should definitely be documented or clearly stated in the release notes. was (Author: jmborer): Remember that it is not only the IDE that get impacted. We have several NB platform apps, that we upgrade on a regular base and still have to use Java 8. It means that we cannot use any version after 12.5 without upgrading to JDK 9+. This should definitely be documented or clearly stated in the release notes. > Netbeans 12.6 seems no properly run on JDK 8 > > > Key: NETBEANS-6285 > URL: https://issues.apache.org/jira/browse/NETBEANS-6285 > Project: NetBeans > Issue Type: Bug > Components: java - Platform >Affects Versions: 12.6 >Reporter: Jean-Marc Borer >Priority: Major > Attachments: messages.log > > > After a full fresh install of NB12.6 and trying to run with Azul Open JDK 1.8 > 312, there are several ClassNotFoundExceptions in the logs. It seems that NB > looks for missing methods that make NB not longer properly. For example, it > is no longer possible to properly format Java sources files due to a > java/nio/CharBuffer method missing. > Is NB platform supposed to no longer work with Java 8? -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-6285) Netbeans 12.6 seems no properly run on JDK 8
[ https://issues.apache.org/jira/browse/NETBEANS-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468395#comment-17468395 ] Jean-Marc Borer commented on NETBEANS-6285: --- Remember that it is not only the IDE that get impacted. We have several NB platform apps, that we upgrade on a regular base and still have to use Java 8. It means that we cannot use any version after 12.5 without upgrading to JDK 9+. This should definitely be documented or clearly stated in the release notes. > Netbeans 12.6 seems no properly run on JDK 8 > > > Key: NETBEANS-6285 > URL: https://issues.apache.org/jira/browse/NETBEANS-6285 > Project: NetBeans > Issue Type: Bug > Components: java - Platform >Affects Versions: 12.6 >Reporter: Jean-Marc Borer >Priority: Major > Attachments: messages.log > > > After a full fresh install of NB12.6 and trying to run with Azul Open JDK 1.8 > 312, there are several ClassNotFoundExceptions in the logs. It seems that NB > looks for missing methods that make NB not longer properly. For example, it > is no longer possible to properly format Java sources files due to a > java/nio/CharBuffer method missing. > Is NB platform supposed to no longer work with Java 8? -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-6285) Netbeans 12.6 seems no properly run on JDK 8
[ https://issues.apache.org/jira/browse/NETBEANS-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer updated NETBEANS-6285: -- Description: After a full fresh install of NB12.6 and trying to run with Azul Open JDK 1.8 312, there are several ClassNotFoundExceptions in the logs. It seems that NB looks for missing methods that make NB not longer properly. For example, it is no longer possible to properly format Java sources files due to a java/nio/CharBuffer method missing. Is NB platform supposed to no longer work with Java 8? was: After a fully fresh install of NB12.6 and trying to run on Azul Open JDK 312, there are several ClassNotFoundExceptions in the logs. It seems that NB looks for missing methods that makes NB not longer properly. For example, it is no longer possible to properly format Java sources files do to a java/nio/CharBuffer method missing. Is NB platform supposed to no longer work with Java 8? > Netbeans 12.6 seems no properly run on JDK 8 > > > Key: NETBEANS-6285 > URL: https://issues.apache.org/jira/browse/NETBEANS-6285 > Project: NetBeans > Issue Type: Bug > Components: java - Platform >Affects Versions: 12.6 >Reporter: Jean-Marc Borer >Priority: Major > Attachments: messages.log > > > After a full fresh install of NB12.6 and trying to run with Azul Open JDK 1.8 > 312, there are several ClassNotFoundExceptions in the logs. It seems that NB > looks for missing methods that make NB not longer properly. For example, it > is no longer possible to properly format Java sources files due to a > java/nio/CharBuffer method missing. > Is NB platform supposed to no longer work with Java 8? -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-6285) Netbeans 12.6 seems no properly run on JDK 8
[ https://issues.apache.org/jira/browse/NETBEANS-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer updated NETBEANS-6285: -- Issue Type: Bug (was: Improvement) > Netbeans 12.6 seems no properly run on JDK 8 > > > Key: NETBEANS-6285 > URL: https://issues.apache.org/jira/browse/NETBEANS-6285 > Project: NetBeans > Issue Type: Bug > Components: java - Platform >Affects Versions: 12.6 >Reporter: Jean-Marc Borer >Priority: Major > Attachments: messages.log > > > After a fully fresh install of NB12.6 and trying to run on Azul Open JDK 312, > there are several ClassNotFoundExceptions in the logs. It seems that NB looks > for missing methods that makes NB not longer properly. For example, it is no > longer possible to properly format Java sources files do to a > java/nio/CharBuffer method missing. > Is NB platform supposed to no longer work with Java 8? -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-5292) nb-javac is source of several issues
[ https://issues.apache.org/jira/browse/NETBEANS-5292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457098#comment-17457098 ] Jean-Marc Borer commented on NETBEANS-5292: --- I also run into this problem on other places. It seems to be related to the fact that now NB uses methods that did not exist in Java 8 > nb-javac is source of several issues > > > Key: NETBEANS-5292 > URL: https://issues.apache.org/jira/browse/NETBEANS-5292 > Project: NetBeans > Issue Type: Bug > Components: java - Compiler, java - Editor, java - Hints, platform - > Action Items >Affects Versions: 11.3, 12.2, 12.4 > Environment: Gradle 6.8.1 > Possibly any JDK version 11 > nb-javac installed >Reporter: Netbeans User 2019 >Priority: Critical > Labels: hints, nbjavac, nbjavac-impl.jar > > There are several issue reporting NullPointerException and in logs even > several related to hints (In context of Tools > Options > Editor > Hints). > So my suggestions are: > 1) to be deactivated all hints and retested with and with and without > nb-javac as seems that many issue like this is connected nb-javac, but It > could be even possible that hints are not revised at all from start and even > it is possible that could be ticked to run by import from prior version of > Netbeans, but it could be unsupported in new version. > 2) turn off of nb-javac does not fix issues like these, because it seems that > that states is ignored and nb-javac is still somehow in use ... so only > option is to uninstalled completely (so to see in notification request for > installation) - so it has to be fixed that if it is inactivated should not be > used > 3) to be added even new feature to reset all Hints to default > 4) seems that even some of such failure (even reported as race condition) > that leads to cases that it is not finished indexing so particular classes > are not index so even not visible by dialog to of types and in java editor is > represented as errors and there is not way to removed that reds, because > there are no way to tell to Apache Netbeans that such class is existing and > it is correct. > 5) "Background scanning of projects..." is even running for minutes with > nb-javac installed > Even if it is not done in minor version I would like to see it in major > version fixed. > To me it seems that nb-javac brings more issue than save -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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] [Created] (NETBEANS-6285) Netbeans 12.6 seems no properly run on JDK 8
Jean-Marc Borer created NETBEANS-6285: - Summary: Netbeans 12.6 seems no properly run on JDK 8 Key: NETBEANS-6285 URL: https://issues.apache.org/jira/browse/NETBEANS-6285 Project: NetBeans Issue Type: Improvement Components: java - Platform Affects Versions: 12.6 Reporter: Jean-Marc Borer Attachments: messages.log After a fully fresh install of NB12.6 and trying to run on Azul Open JDK 312, there are several ClassNotFoundExceptions in the logs. It seems that NB looks for missing methods that makes NB not longer properly. For example, it is no longer possible to properly format Java sources files do to a java/nio/CharBuffer method missing. Is NB platform supposed to no longer work with Java 8? -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-3810) Netbeans 11.3 does not report clearly certificate problems downloading javafx and nb-javac
[ https://issues.apache.org/jira/browse/NETBEANS-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107053#comment-17107053 ] Jean-Marc Borer edited comment on NETBEANS-3810 at 5/14/20, 8:05 AM: - This is a very nice plugin. It think it shall be part of the Netbeans distribution (same as IntelliJ). So much less pain for newcomers to use the IDE. was (Author: jmborer): This is a very nice plugin. It think it shall be part of the Netbeans distribution (same as IntelliJ). > Netbeans 11.3 does not report clearly certificate problems downloading javafx > and nb-javac > -- > > Key: NETBEANS-3810 > URL: https://issues.apache.org/jira/browse/NETBEANS-3810 > Project: NetBeans > Issue Type: Bug > Components: platform - Autoupdate >Affects Versions: 11.3 > Environment: Windows 2016 server, Intel Xeon, 48G RAM. > Network includes a proxy server with deep packet inspection and certificate > rewriting. >Reporter: Michele Costabile >Assignee: Michele Costabile >Priority: Minor > Labels: documentation, newbie > Fix For: 11.3 > > Attachments: Netbeans-11.3_bug.PNG, Netbeans-11.3_plugin-problem.PNG, > Netbeans-11.3_plugin.PNG > > > NetBeans cannot get past installation of JavaFX and nb-javac on my > installation behind a company firewall. This problem was also in 11.2, but it > did not stop the IDE from working. It just kept on quietly asking for > nb-javac installation. > 11.3, on the other hand does not seem to get past this problem. It keeps on > asking for installation of javafx and nb-javac and "Loading projects" never > comes to an end. > I tested my proxy setting in options and I have a green light with system > settings and also with manual settings. > In any case I have never been able to install nb-javac and could not find > instructions on how to install manually the plugin. > Note that my proxy has deep packet inspection and can create problems with > certificate verification on SSL. > > EDIT: the request for installation is not an infinite loop. It appears to be > once for every open project. Hitting cancel more times, the progress bar in > the status bar eventually gets to 100%, but all the projects are reported > broken. > > EDIT: as you can see from the comments below, it was really a problem with > certificates. When you are behind a proxy with deep inspection, certificates > are manipulated in such a way that you have to trust your company root > certificate to avoid failure in trust chains. > This becomes a NetBeans installation problem because: > * Differently from other IDEs, NetBeans delegates everything to JDK, so it > requires that the trust problem is solved in the JDK, not in the IDE > preferences. The user should be able to find instructionsto resolve the > problem > * In 11.2 the IDE did not enter a loop waiting for nb'javac installation to > validate projects. It just gave up, causing less problems > * "Test connection" in proxy settings did not report certificate problems. A > full https connection should be tested > * The dialog box of nb-javac installation does not report certificate > problems, it rather dies without warning and the installation is stuck with a > progress bar at 100% and no notification other than "cannot resolve external > references ..." This hides the problem > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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-3810) Netbeans 11.3 does not report clearly certificate problems downloading javafx and nb-javac
[ https://issues.apache.org/jira/browse/NETBEANS-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107053#comment-17107053 ] Jean-Marc Borer commented on NETBEANS-3810: --- This is a very nice plugin. It think it shall be part of the Netbeans distribution (same as IntelliJ). > Netbeans 11.3 does not report clearly certificate problems downloading javafx > and nb-javac > -- > > Key: NETBEANS-3810 > URL: https://issues.apache.org/jira/browse/NETBEANS-3810 > Project: NetBeans > Issue Type: Bug > Components: platform - Autoupdate >Affects Versions: 11.3 > Environment: Windows 2016 server, Intel Xeon, 48G RAM. > Network includes a proxy server with deep packet inspection and certificate > rewriting. >Reporter: Michele Costabile >Assignee: Michele Costabile >Priority: Minor > Labels: documentation, newbie > Fix For: 11.3 > > Attachments: Netbeans-11.3_bug.PNG, Netbeans-11.3_plugin-problem.PNG, > Netbeans-11.3_plugin.PNG > > > NetBeans cannot get past installation of JavaFX and nb-javac on my > installation behind a company firewall. This problem was also in 11.2, but it > did not stop the IDE from working. It just kept on quietly asking for > nb-javac installation. > 11.3, on the other hand does not seem to get past this problem. It keeps on > asking for installation of javafx and nb-javac and "Loading projects" never > comes to an end. > I tested my proxy setting in options and I have a green light with system > settings and also with manual settings. > In any case I have never been able to install nb-javac and could not find > instructions on how to install manually the plugin. > Note that my proxy has deep packet inspection and can create problems with > certificate verification on SSL. > > EDIT: the request for installation is not an infinite loop. It appears to be > once for every open project. Hitting cancel more times, the progress bar in > the status bar eventually gets to 100%, but all the projects are reported > broken. > > EDIT: as you can see from the comments below, it was really a problem with > certificates. When you are behind a proxy with deep inspection, certificates > are manipulated in such a way that you have to trust your company root > certificate to avoid failure in trust chains. > This becomes a NetBeans installation problem because: > * Differently from other IDEs, NetBeans delegates everything to JDK, so it > requires that the trust problem is solved in the JDK, not in the IDE > preferences. The user should be able to find instructionsto resolve the > problem > * In 11.2 the IDE did not enter a loop waiting for nb'javac installation to > validate projects. It just gave up, causing less problems > * "Test connection" in proxy settings did not report certificate problems. A > full https connection should be tested > * The dialog box of nb-javac installation does not report certificate > problems, it rather dies without warning and the installation is stuck with a > progress bar at 100% and no notification other than "cannot resolve external > references ..." This hides the problem > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] [Closed] (NETBEANSINFRA-188) Fix slow copies of module jar files
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer closed NETBEANSINFRA-188. - Successful build on Jenkins > Fix slow copies of module jar files > --- > > Key: NETBEANSINFRA-188 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-188 > Project: Apache NetBeans Infra > Issue Type: Improvement > Components: MU - Apache NetBeans NBM maven plugin >Reporter: Jean-Marc Borer >Assignee: Jean-Marc Borer >Priority: Minor > Labels: pull-request-available > Fix For: NBM Maven Plugin 4.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] [Resolved] (NETBEANSINFRA-188) Fix slow copies of module jar files
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer resolved NETBEANSINFRA-188. --- Resolution: Fixed Merged PR: https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin/commit/56ef3d3d69a057bc6528806127043d322b832170 > Fix slow copies of module jar files > --- > > Key: NETBEANSINFRA-188 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-188 > Project: Apache NetBeans Infra > Issue Type: Improvement > Components: MU - Apache NetBeans NBM maven plugin >Reporter: Jean-Marc Borer >Assignee: Jean-Marc Borer >Priority: Minor > Labels: pull-request-available > Fix For: NBM Maven Plugin 4.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] [Assigned] (NETBEANSINFRA-188) Fix slow copies of module jar files
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer reassigned NETBEANSINFRA-188: - Assignee: Jean-Marc Borer > Fix slow copies of module jar files > --- > > Key: NETBEANSINFRA-188 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-188 > Project: Apache NetBeans Infra > Issue Type: Improvement > Components: MU - Apache NetBeans NBM maven plugin >Reporter: Jean-Marc Borer >Assignee: Jean-Marc Borer >Priority: Minor > Labels: pull-request-available > Fix For: NBM Maven Plugin 4.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] [Created] (NETBEANSINFRA-188) Fix slow copies of module jar files
Jean-Marc Borer created NETBEANSINFRA-188: - Summary: Fix slow copies of module jar files Key: NETBEANSINFRA-188 URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-188 Project: Apache NetBeans Infra Issue Type: Improvement Components: MU - Apache NetBeans NBM maven plugin Reporter: Jean-Marc Borer Fix For: NBM Maven Plugin 4.6 -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] [Resolved] (NETBEANSINFRA-187) nbmBuildDir conflict between targets nbm and cluster because of wrong usage
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer resolved NETBEANSINFRA-187. --- Resolution: Fixed Fixed and committed to master > nbmBuildDir conflict between targets nbm and cluster because of wrong usage > --- > > Key: NETBEANSINFRA-187 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-187 > Project: Apache NetBeans Infra > Issue Type: Bug > Components: MU - Apache NetBeans NBM maven plugin >Affects Versions: NBM Maven Plugin 4.5 >Reporter: Jean-Marc Borer >Assignee: Jean-Marc Borer >Priority: Major > Labels: pull-request-available > Fix For: NBM Maven Plugin 4.6 > > > The nbmBuildIDir parameter is used both in nbm and cluster targets. However > the meaning in those two contexts are different: > 1) nbm: output directory where the NBMs will be created from the Jars and > other meta data > 2) cluster: directory where to copy the NBMS to from the hardcoded > $(based}/nbm/netbeans > This is usually not a problem as long a you work with netbeans, but it > becomes if you want to use the targets with other projects such as VisualVM. > By looking at the code, this seems more a like bug. What the cluster target > should actually do is look for the NBMs, not in the hard coded location, but > in the one provided by nbmBuildDir and use clusterBuildDir instead to define > the target cluster location build. This very same parameter will be reused by > the run-ide target. -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] [Closed] (NETBEANSINFRA-187) nbmBuildDir conflict between targets nbm and cluster because of wrong usage
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer closed NETBEANSINFRA-187. - Tested > nbmBuildDir conflict between targets nbm and cluster because of wrong usage > --- > > Key: NETBEANSINFRA-187 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-187 > Project: Apache NetBeans Infra > Issue Type: Bug > Components: MU - Apache NetBeans NBM maven plugin >Affects Versions: NBM Maven Plugin 4.5 >Reporter: Jean-Marc Borer >Assignee: Jean-Marc Borer >Priority: Major > Labels: pull-request-available > Fix For: NBM Maven Plugin 4.6 > > > The nbmBuildIDir parameter is used both in nbm and cluster targets. However > the meaning in those two contexts are different: > 1) nbm: output directory where the NBMs will be created from the Jars and > other meta data > 2) cluster: directory where to copy the NBMS to from the hardcoded > $(based}/nbm/netbeans > This is usually not a problem as long a you work with netbeans, but it > becomes if you want to use the targets with other projects such as VisualVM. > By looking at the code, this seems more a like bug. What the cluster target > should actually do is look for the NBMs, not in the hard coded location, but > in the one provided by nbmBuildDir and use clusterBuildDir instead to define > the target cluster location build. This very same parameter will be reused by > the run-ide target. -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] (NETBEANSINFRA-187) nbmBuildDir conflict between targets nbm and cluster because of wrong usage
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer updated NETBEANSINFRA-187: -- Fix Version/s: NBM Maven Plugin 4.6 Affects Version/s: NBM Maven Plugin 4.5 > nbmBuildDir conflict between targets nbm and cluster because of wrong usage > --- > > Key: NETBEANSINFRA-187 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-187 > Project: Apache NetBeans Infra > Issue Type: Bug > Components: MU - Apache NetBeans NBM maven plugin >Affects Versions: NBM Maven Plugin 4.5 >Reporter: Jean-Marc Borer >Assignee: Jean-Marc Borer >Priority: Major > Labels: pull-request-available > Fix For: NBM Maven Plugin 4.6 > > > The nbmBuildIDir parameter is used both in nbm and cluster targets. However > the meaning in those two contexts are different: > 1) nbm: output directory where the NBMs will be created from the Jars and > other meta data > 2) cluster: directory where to copy the NBMS to from the hardcoded > $(based}/nbm/netbeans > This is usually not a problem as long a you work with netbeans, but it > becomes if you want to use the targets with other projects such as VisualVM. > By looking at the code, this seems more a like bug. What the cluster target > should actually do is look for the NBMs, not in the hard coded location, but > in the one provided by nbmBuildDir and use clusterBuildDir instead to define > the target cluster location build. This very same parameter will be reused by > the run-ide target. -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] [Assigned] (NETBEANSINFRA-187) nbmBuildDir conflict between targets nbm and cluster because of wrong usage
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer reassigned NETBEANSINFRA-187: - Assignee: Jean-Marc Borer > nbmBuildDir conflict between targets nbm and cluster because of wrong usage > --- > > Key: NETBEANSINFRA-187 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-187 > Project: Apache NetBeans Infra > Issue Type: Bug > Components: MU - Apache NetBeans NBM maven plugin >Reporter: Jean-Marc Borer >Assignee: Jean-Marc Borer >Priority: Major > Labels: pull-request-available > > The nbmBuildIDir parameter is used both in nbm and cluster targets. However > the meaning in those two contexts are different: > 1) nbm: output directory where the NBMs will be created from the Jars and > other meta data > 2) cluster: directory where to copy the NBMS to from the hardcoded > $(based}/nbm/netbeans > This is usually not a problem as long a you work with netbeans, but it > becomes if you want to use the targets with other projects such as VisualVM. > By looking at the code, this seems more a like bug. What the cluster target > should actually do is look for the NBMs, not in the hard coded location, but > in the one provided by nbmBuildDir and use clusterBuildDir instead to define > the target cluster location build. This very same parameter will be reused by > the run-ide target. -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] (NETBEANSINFRA-187) nbmBuildDir conflict between targets nbm and cluster because of wrong usage
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17092651#comment-17092651 ] Jean-Marc Borer edited comment on NETBEANSINFRA-187 at 4/26/20, 12:08 PM: -- Hi. I have cloned the code and am working on a fix. It is almost ready, but I'll do a PR when it is completely finished. FYI, I am a Netbeans PMC. You can assign this issue to me, if you'd like. Best regards, JM was (Author: jmborer): Hi. I have cloned the code and am working on fix. It is almost ready, but I'll do a PR when it is completely finished. FYI, I am a Netbeans PMC. You can assign this issue to me, if you'd like. Best regards, JM > nbmBuildDir conflict between targets nbm and cluster because of wrong usage > --- > > Key: NETBEANSINFRA-187 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-187 > Project: Apache NetBeans Infra > Issue Type: Bug > Components: MU - Apache NetBeans NBM maven plugin >Reporter: Jean-Marc Borer >Priority: Major > > The nbmBuildIDir parameter is used both in nbm and cluster targets. However > the meaning in those two contexts are different: > 1) nbm: output directory where the NBMs will be created from the Jars and > other meta data > 2) cluster: directory where to copy the NBMS to from the hardcoded > $(based}/nbm/netbeans > This is usually not a problem as long a you work with netbeans, but it > becomes if you want to use the targets with other projects such as VisualVM. > By looking at the code, this seems more a like bug. What the cluster target > should actually do is look for the NBMs, not in the hard coded location, but > in the one provided by nbmBuildDir and use clusterBuildDir instead to define > the target cluster location build. This very same parameter will be reused by > the run-ide target. -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] (NETBEANSINFRA-187) nbmBuildDir conflict between targets nbm and cluster because of wrong usage
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17092651#comment-17092651 ] Jean-Marc Borer edited comment on NETBEANSINFRA-187 at 4/26/20, 10:41 AM: -- Hi. I have cloned the code and am working on fix. It is almost ready, but I'll do a PR when it is completely finished. FYI, I am a Netbeans PMC. You can assign this issue to me, if you'd like. Best regards, JM was (Author: jmborer): Hi. I have cloned the code and am working on fix. It is almost ready, but I'll do a PR when it is completely finished. > nbmBuildDir conflict between targets nbm and cluster because of wrong usage > --- > > Key: NETBEANSINFRA-187 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-187 > Project: Apache NetBeans Infra > Issue Type: Bug > Components: MU - Apache NetBeans NBM maven plugin >Reporter: Jean-Marc Borer >Priority: Major > > The nbmBuildIDir parameter is used both in nbm and cluster targets. However > the meaning in those two contexts are different: > 1) nbm: output directory where the NBMs will be created from the Jars and > other meta data > 2) cluster: directory where to copy the NBMS to from the hardcoded > $(based}/nbm/netbeans > This is usually not a problem as long a you work with netbeans, but it > becomes if you want to use the targets with other projects such as VisualVM. > By looking at the code, this seems more a like bug. What the cluster target > should actually do is look for the NBMs, not in the hard coded location, but > in the one provided by nbmBuildDir and use clusterBuildDir instead to define > the target cluster location build. This very same parameter will be reused by > the run-ide target. -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] (NETBEANSINFRA-187) nbmBuildDir conflict between targets nbm and cluster because of wrong usage
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17092651#comment-17092651 ] Jean-Marc Borer edited comment on NETBEANSINFRA-187 at 4/26/20, 10:40 AM: -- Hi. I have cloned the code and am working on fix. It is almost ready, but I'll do a PR when it is completely finished. was (Author: jmborer): Hi. I have cloned the code and am working on fix. It is almost ready, but I'll do a PR when it is completely finished. > nbmBuildDir conflict between targets nbm and cluster because of wrong usage > --- > > Key: NETBEANSINFRA-187 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-187 > Project: Apache NetBeans Infra > Issue Type: Bug > Components: MU - Apache NetBeans NBM maven plugin >Reporter: Jean-Marc Borer >Priority: Major > > The nbmBuildIDir parameter is used both in nbm and cluster targets. However > the meaning in those two contexts are different: > 1) nbm: output directory where the NBMs will be created from the Jars and > other meta data > 2) cluster: directory where to copy the NBMS to from the hardcoded > $(based}/nbm/netbeans > This is usually not a problem as long a you work with netbeans, but it > becomes if you want to use the targets with other projects such as VisualVM. > By looking at the code, this seems more a like bug. What the cluster target > should actually do is look for the NBMs, not in the hard coded location, but > in the one provided by nbmBuildDir and use clusterBuildDir instead to define > the target cluster location build. This very same parameter will be reused by > the run-ide target. -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] (NETBEANSINFRA-187) nbmBuildDir conflict between targets nbm and cluster because of wrong usage
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17092651#comment-17092651 ] Jean-Marc Borer commented on NETBEANSINFRA-187: --- Hi. I have cloned the code and am working on fix. It is almost ready, but I'll do a PR when it is completely finished. > nbmBuildDir conflict between targets nbm and cluster because of wrong usage > --- > > Key: NETBEANSINFRA-187 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-187 > Project: Apache NetBeans Infra > Issue Type: Bug > Components: MU - Apache NetBeans NBM maven plugin >Reporter: Jean-Marc Borer >Priority: Major > > The nbmBuildIDir parameter is used both in nbm and cluster targets. However > the meaning in those two contexts are different: > 1) nbm: output directory where the NBMs will be created from the Jars and > other meta data > 2) cluster: directory where to copy the NBMS to from the hardcoded > $(based}/nbm/netbeans > This is usually not a problem as long a you work with netbeans, but it > becomes if you want to use the targets with other projects such as VisualVM. > By looking at the code, this seems more a like bug. What the cluster target > should actually do is look for the NBMs, not in the hard coded location, but > in the one provided by nbmBuildDir and use clusterBuildDir instead to define > the target cluster location build. This very same parameter will be reused by > the run-ide target. -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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] [Created] (NETBEANSINFRA-187) nbmBuildDir conflict between targets nbm and cluster because of wrong usage
Jean-Marc Borer created NETBEANSINFRA-187: - Summary: nbmBuildDir conflict between targets nbm and cluster because of wrong usage Key: NETBEANSINFRA-187 URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-187 Project: Apache NetBeans Infra Issue Type: Bug Components: MU - Apache NetBeans NBM maven plugin Reporter: Jean-Marc Borer The nbmBuildIDir parameter is used both in nbm and cluster targets. However the meaning in those two contexts are different: 1) nbm: output directory where the NBMs will be created from the Jars and other meta data 2) cluster: directory where to copy the NBMS to from the hardcoded $(based}/nbm/netbeans This is usually not a problem as long a you work with netbeans, but it becomes if you want to use the targets with other projects such as VisualVM. By looking at the code, this seems more a like bug. What the cluster target should actually do is look for the NBMs, not in the hard coded location, but in the one provided by nbmBuildDir and use clusterBuildDir instead to define the target cluster location build. This very same parameter will be reused by the run-ide target. -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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-3810) Netbeans 11.3 does not report clearly certificate problems downloading javafx and nb-javac
[ https://issues.apache.org/jira/browse/NETBEANS-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039236#comment-17039236 ] Jean-Marc Borer edited comment on NETBEANS-3810 at 2/18/20 4:55 PM: These self signed CA certificates bring a lot of problems with any application that try to do HTTPS connections (not only Java based ones). Unfortunately companies use this approach mainly for cost reasons. Would they have used a certificate from a trusted authority, then it wouldn't be a problem. sigh. was (Author: jmborer): These self signed CA certificates bring a lot of problems with any application that tries to do HTTPS connections (not only Java based ones). Unfortunately companies use this approach mainly for cost reasons. Would they have used a certificate from a trusted authority, then it wouldn't be a problem. sigh. > Netbeans 11.3 does not report clearly certificate problems downloading javafx > and nb-javac > -- > > Key: NETBEANS-3810 > URL: https://issues.apache.org/jira/browse/NETBEANS-3810 > Project: NetBeans > Issue Type: Bug > Components: platform - Autoupdate >Affects Versions: 11.3 > Environment: Windows 2016 server, Intel Xeon, 48G RAM. > Network includes a proxy server with deep packet inspection and certificate > rewriting. >Reporter: Michele Costabile >Assignee: Michele Costabile >Priority: Minor > Labels: documentation, newbie > Fix For: 11.3 > > Attachments: Netbeans-11.3_bug.PNG, Netbeans-11.3_plugin-problem.PNG, > Netbeans-11.3_plugin.PNG > > > NetBeans cannot get past installation of JavaFX and nb-javac on my > installation behind a company firewall. This problem was also in 11.2, but it > did not stop the IDE from working. It just kept on quietly asking for > nb-javac installation. > 11.3, on the other hand does not seem to get past this problem. It keeps on > asking for installation of javafx and nb-javac and "Loading projects" never > comes to an end. > I tested my proxy setting in options and I have a green light with system > settings and also with manual settings. > In any case I have never been able to install nb-javac and could not find > instructions on how to install manually the plugin. > Note that my proxy has deep packet inspection and can create problems with > certificate verification on SSL. > > EDIT: the request for installation is not an infinite loop. It appears to be > once for every open project. Hitting cancel more times, the progress bar in > the status bar eventually gets to 100%, but all the projects are reported > broken. > > EDIT: as you can see from the comments below, it was really a problem with > certificates. When you are behind a proxy with deep inspection, certificates > are manipulated in such a way that you have to trust your company root > certificate to avoid failure in trust chains. > This becomes a NetBeans installation problem because: > * Differently from other IDEs, NetBeans delegates everything to JDK, so it > requires that the trust problem is solved in the JDK, not in the IDE > preferences. The user should be able to find instructionsto resolve the > problem > * In 11.2 the IDE did not enter a loop waiting for nb'javac installation to > validate projects. It just gave up, causing less problems > * "Test connection" in proxy settings did not report certificate problems. A > full https connection should be tested > * The dialog box of nb-javac installation does not report certificate > problems, it rather dies without warning and the installation is stuck with a > progress bar at 100% and no notification other than "cannot resolve external > references ..." This hides the problem > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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-3810) Netbeans 11.3 does not report clearly certificate problems downloading javafx and nb-javac
[ https://issues.apache.org/jira/browse/NETBEANS-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039236#comment-17039236 ] Jean-Marc Borer commented on NETBEANS-3810: --- These self signed CA certificates bring a lot of problems with any application that tries to do HTTPS connections (not only Java based ones). Unfortunately companies use this approach mainly for cost reasons. Would they have used a certificate from a trusted authority, then it wouldn't be a problem. sigh. > Netbeans 11.3 does not report clearly certificate problems downloading javafx > and nb-javac > -- > > Key: NETBEANS-3810 > URL: https://issues.apache.org/jira/browse/NETBEANS-3810 > Project: NetBeans > Issue Type: Bug > Components: platform - Autoupdate >Affects Versions: 11.3 > Environment: Windows 2016 server, Intel Xeon, 48G RAM. > Network includes a proxy server with deep packet inspection and certificate > rewriting. >Reporter: Michele Costabile >Assignee: Michele Costabile >Priority: Minor > Labels: documentation, newbie > Fix For: 11.3 > > Attachments: Netbeans-11.3_bug.PNG, Netbeans-11.3_plugin-problem.PNG, > Netbeans-11.3_plugin.PNG > > > NetBeans cannot get past installation of JavaFX and nb-javac on my > installation behind a company firewall. This problem was also in 11.2, but it > did not stop the IDE from working. It just kept on quietly asking for > nb-javac installation. > 11.3, on the other hand does not seem to get past this problem. It keeps on > asking for installation of javafx and nb-javac and "Loading projects" never > comes to an end. > I tested my proxy setting in options and I have a green light with system > settings and also with manual settings. > In any case I have never been able to install nb-javac and could not find > instructions on how to install manually the plugin. > Note that my proxy has deep packet inspection and can create problems with > certificate verification on SSL. > > EDIT: the request for installation is not an infinite loop. It appears to be > once for every open project. Hitting cancel more times, the progress bar in > the status bar eventually gets to 100%, but all the projects are reported > broken. > > EDIT: as you can see from the comments below, it was really a problem with > certificates. When you are behind a proxy with deep inspection, certificates > are manipulated in such a way that you have to trust your company root > certificate to avoid failure in trust chains. > This becomes a NetBeans installation problem because: > * Differently from other IDEs, NetBeans delegates everything to JDK, so it > requires that the trust problem is solved in the JDK, not in the IDE > preferences. The user should be able to find instructionsto resolve the > problem > * In 11.2 the IDE did not enter a loop waiting for nb'javac installation to > validate projects. It just gave up, causing less problems > * "Test connection" in proxy settings did not report certificate problems. A > full https connection should be tested > * The dialog box of nb-javac installation does not report certificate > problems, it rather dies without warning and the installation is stuck with a > progress bar at 100% and no notification other than "cannot resolve external > references ..." This hides the problem > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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-3810) Netbeans 11.3 does not report clearly certificate problems downloading javafx and nb-javac
[ https://issues.apache.org/jira/browse/NETBEANS-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039186#comment-17039186 ] Jean-Marc Borer edited comment on NETBEANS-3810 at 2/18/20 3:57 PM: I have exactly the very same issue. Moreover, my company uses its own self-signed certificate and not one from a known provider. I think Michele is in the exact same situation. Therefore we must both install the root CA among the trusted CAs was (Author: jmborer): I have exactly the very same issue. Moreover, my company uses its own self-signed certificate and not one from a know provider. I think Michele is in the exact same situation. Therefore we must both install the root CA among the trusted CAs > Netbeans 11.3 does not report clearly certificate problems downloading javafx > and nb-javac > -- > > Key: NETBEANS-3810 > URL: https://issues.apache.org/jira/browse/NETBEANS-3810 > Project: NetBeans > Issue Type: Bug > Components: platform - Autoupdate >Affects Versions: 11.3 > Environment: Windows 2016 server, Intel Xeon, 48G RAM. > Network includes a proxy server with deep packet inspection and certificate > rewriting. >Reporter: Michele Costabile >Assignee: Michele Costabile >Priority: Minor > Labels: documentation, newbie > Fix For: 11.3 > > Attachments: Netbeans-11.3_bug.PNG, Netbeans-11.3_plugin-problem.PNG, > Netbeans-11.3_plugin.PNG > > > NetBeans cannot get past installation of JavaFX and nb-javac on my > installation behind a company firewall. This problem was also in 11.2, but it > did not stop the IDE from working. It just kept on quietly asking for > nb-javac installation. > 11.3, on the other hand does not seem to get past this problem. It keeps on > asking for installation of javafx and nb-javac and "Loading projects" never > comes to an end. > I tested my proxy setting in options and I have a green light with system > settings and also with manual settings. > In any case I have never been able to install nb-javac and could not find > instructions on how to install manually the plugin. > Note that my proxy has deep packet inspection and can create problems with > certificate verification on SSL. > > EDIT: the request for installation is not an infinite loop. It appears to be > once for every open project. Hitting cancel more times, the progress bar in > the status bar eventually gets to 100%, but all the projects are reported > broken. > > EDIT: as you can see from the comments below, it was really a problem with > certificates. When you are behind a proxy with deep inspection, certificates > are manipulated in such a way that you have to trust your company root > certificate to avoid failure in trust chains. > This becomes a NetBeans installation problem because: > * Differently from other IDEs, NetBeans delegates everything to JDK, so it > requires that the trust problem is solved in the JDK, not in the IDE > preferences. The user should be able to find instructionsto resolve the > problem > * In 11.2 the IDE did not enter a loop waiting for nb'javac installation to > validate projects. It just gave up, causing less problems > * "Test connection" in proxy settings did not report certificate problems. A > full https connection should be tested > * The dialog box of nb-javac installation does not report certificate > problems, it rather dies without warning and the installation is stuck with a > progress bar at 100% and no notification other than "cannot resolve external > references ..." This hides the problem > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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-3810) Netbeans 11.3 does not report clearly certificate problems downloading javafx and nb-javac
[ https://issues.apache.org/jira/browse/NETBEANS-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039186#comment-17039186 ] Jean-Marc Borer commented on NETBEANS-3810: --- I have exactly the very same issue. Moreover, my company uses its own self-signed certificate and not one from a know provider. I think Michele is in the exact same situation. Therefore we must both install the root CA among the trusted CAs > Netbeans 11.3 does not report clearly certificate problems downloading javafx > and nb-javac > -- > > Key: NETBEANS-3810 > URL: https://issues.apache.org/jira/browse/NETBEANS-3810 > Project: NetBeans > Issue Type: Bug > Components: platform - Autoupdate >Affects Versions: 11.3 > Environment: Windows 2016 server, Intel Xeon, 48G RAM. > Network includes a proxy server with deep packet inspection and certificate > rewriting. >Reporter: Michele Costabile >Assignee: Michele Costabile >Priority: Minor > Labels: documentation, newbie > Fix For: 11.3 > > Attachments: Netbeans-11.3_bug.PNG, Netbeans-11.3_plugin-problem.PNG, > Netbeans-11.3_plugin.PNG > > > NetBeans cannot get past installation of JavaFX and nb-javac on my > installation behind a company firewall. This problem was also in 11.2, but it > did not stop the IDE from working. It just kept on quietly asking for > nb-javac installation. > 11.3, on the other hand does not seem to get past this problem. It keeps on > asking for installation of javafx and nb-javac and "Loading projects" never > comes to an end. > I tested my proxy setting in options and I have a green light with system > settings and also with manual settings. > In any case I have never been able to install nb-javac and could not find > instructions on how to install manually the plugin. > Note that my proxy has deep packet inspection and can create problems with > certificate verification on SSL. > > EDIT: the request for installation is not an infinite loop. It appears to be > once for every open project. Hitting cancel more times, the progress bar in > the status bar eventually gets to 100%, but all the projects are reported > broken. > > EDIT: as you can see from the comments below, it was really a problem with > certificates. When you are behind a proxy with deep inspection, certificates > are manipulated in such a way that you have to trust your company root > certificate to avoid failure in trust chains. > This becomes a NetBeans installation problem because: > * Differently from other IDEs, NetBeans delegates everything to JDK, so it > requires that the trust problem is solved in the JDK, not in the IDE > preferences. The user should be able to find instructionsto resolve the > problem > * In 11.2 the IDE did not enter a loop waiting for nb'javac installation to > validate projects. It just gave up, causing less problems > * "Test connection" in proxy settings did not report certificate problems. A > full https connection should be tested > * The dialog box of nb-javac installation does not report certificate > problems, it rather dies without warning and the installation is stuck with a > progress bar at 100% and no notification other than "cannot resolve external > references ..." This hides the problem > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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-3810) Netbeans 11.3 does not report clearly certificate problems downloading javafx and nb-javac
[ https://issues.apache.org/jira/browse/NETBEANS-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17038433#comment-17038433 ] Jean-Marc Borer commented on NETBEANS-3810: --- I was also bitten by this issue. Since I am struggling for a long time with this issue, I knew I have to install the corporate CA root certificate in the JDK keystore that runs the IDE. Sure a proper error message would be much better. I have often an even more vicious issue: whitelisting JARs. For untrusted sites, my proxy returns empty JARS (0K). This is even more difficult to spot because the JDK/IDE thinks it managed to retrieve the item, but actually it is corrupted or incomplete. Here a better error detection would also help to diagnose the issue. > Netbeans 11.3 does not report clearly certificate problems downloading javafx > and nb-javac > -- > > Key: NETBEANS-3810 > URL: https://issues.apache.org/jira/browse/NETBEANS-3810 > Project: NetBeans > Issue Type: Bug > Components: platform - Autoupdate >Affects Versions: 11.3 > Environment: Windows 2016 server, Intel Xeon, 48G RAM. > Network includes a proxy server with deep packet inspection and certificate > rewriting. >Reporter: Michele Costabile >Assignee: Michele Costabile >Priority: Minor > Labels: documentation, newbie > Fix For: 11.3 > > Attachments: Netbeans-11.3_bug.PNG, Netbeans-11.3_plugin-problem.PNG, > Netbeans-11.3_plugin.PNG > > > NetBeans cannot get past installation of JavaFX and nb-javac on my > installation behind a company firewall. This problem was also in 11.2, but it > did not stop the IDE from working. It just kept on quietly asking for > nb-javac installation. > 11.3, on the other hand does not seem to get past this problem. It keeps on > asking for installation of javafx and nb-javac and "Loading projects" never > comes to an end. > I tested my proxy setting in options and I have a green light with system > settings and also with manual settings. > In any case I have never been able to install nb-javac and could not find > instructions on how to install manually the plugin. > Note that my proxy has deep packet inspection and can create problems with > certificate verification on SSL. > > EDIT: the request for installation is not an infinite loop. It appears to be > once for every open project. Hitting cancel more times, the progress bar in > the status bar eventually gets to 100%, but all the projects are reported > broken. > > EDIT: as you can see from the comments below, it was really a problem with > certificates. When you are behind a proxy with deep inspection, certificates > are manipulated in such a way that you have to trust your company root > certificate to avoid failure in trust chains. > This becomes a NetBeans installation problem because: > * Differently from other IDEs, NetBeans delegates everything to JDK, so it > requires that the trust problem is solved in the JDK, not in the IDE > preferences. The user should be able to find instructionsto resolve the > problem > * In 11.2 the IDE did not enter a loop waiting for nb'javac installation to > validate projects. It just gave up, causing less problems > * "Test connection" in proxy settings did not report certificate problems. A > full https connection should be tested > * The dialog box of nb-javac installation does not report certificate > problems, it rather dies without warning and the installation is stuck with a > progress bar at 100% and no notification other than "cannot resolve external > references ..." This hides the problem > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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=16451737#comment-16451737
]
Jean-Marc Borer commented on NETBEANS-58:
-
lbruun wrote:
{quote}I'm partly guilty myself
{quote}
I wish I had the choice at my office :(
> 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 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
[jira] [Comment Edited] (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=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 3:24 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (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=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 3:05 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (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=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:35 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (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=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:33 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (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=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:27 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (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=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:26 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (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=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:18 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
[jira] [Comment Edited] (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=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:16 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)
at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
at
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
sun.net.www.protocol.http.spnego.NegotiatorImpl.init(NegotiatorImpl.java:108)
at
sun.net.www.protocol.http.spnego.NegotiatorImpl.(NegotiatorImpl.java:117)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
[jira] [Comment Edited] (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=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:08 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#ff}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock
{color:#ff}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{noformat}
"org.netbeans.api.keyring.Keyring" #26 daemon prio=1 os_prio=-2
tid=0x19593000 nid=0x1640 waiting for monitor entry [0x2655e000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.netbeans.ModuleManager$SystemClassLoader.getResourcesImpl(ModuleManager.java:708)
- waiting to lock <0xc0d64370> (a
org.netbeans.ModuleManager$SystemClassLoader)
at org.netbeans.ProxyClassLoader.getResources(ProxyClassLoader.java:390)
at
org.openide.util.lookup.MetaInfServicesLookup.search(MetaInfServicesLookup.java:205)
at
org.openide.util.lookup.MetaInfServicesLookup.beforeLookup(MetaInfServicesLookup.java:156)
at
org.openide.util.lookup.MetaInfServicesLookup.beforeLookupResult(MetaInfServicesLookup.java:135)
at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:483)
at org.openide.util.lookup.ProxyLookup$R.initResults(ProxyLookup.java:390)
at org.openide.util.lookup.ProxyLookup$R.myBeforeLookup(ProxyLookup.java:673)
at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:553)
at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:513)
at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:509)
at org.openide.util.Lookup.lookupAll(Lookup.java:312)
at org.netbeans.api.keyring.Keyring.provider(Keyring.java:89)
- locked <0xf0525f68> (a java.lang.Class for
org.netbeans.api.keyring.Keyring)
at org.netbeans.api.keyring.Keyring.readImpl(Keyring.java:105)
- locked <0xf0525f68> (a java.lang.Class for
org.netbeans.api.keyring.Keyring)
at org.netbeans.api.keyring.Keyring.access$100(Keyring.java:75)
at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:128)
at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:125)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
[jira] [Comment Edited] (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=16449908#comment-16449908
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:05 PM:
--
@Geertjan, no it did not happen before. Now, I don't know from when exactly it
started, I mean which JDK/NB version combination. Actually it doesn't matter.
Now it no longer works and the reason has been quite clearly identified: dead
locking while querying the Keyring.
If you look at the extract from my block IDE thread dump you will see that:
1) "Thread-8" takes the lock {color:#FF}0xc0d64370 {color}in
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
Then further down the call stack, it creates a task that will wait forever
reading the a value from Keyring at
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it
tries to get the lock on {color:#FF}0xc0d64370{color}. Boom
deadlock...
This blocks all threads on the ModuleManager$SystemClassLoader lock on
{color:#FF}0xc0d64370 {color}for every other thread including the
AWT Event one which leads to the HMI freeze.
{code:java}
"org.netbeans.api.keyring.Keyring" #26 daemon prio=1 os_prio=-2
tid=0x19593000 nid=0x1640 waiting for monitor entry [0x2655e000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.netbeans.ModuleManager$SystemClassLoader.getResourcesImpl(ModuleManager.java:708)
- waiting to lock <0xc0d64370> (a
org.netbeans.ModuleManager$SystemClassLoader)
at org.netbeans.ProxyClassLoader.getResources(ProxyClassLoader.java:390)
at
org.openide.util.lookup.MetaInfServicesLookup.search(MetaInfServicesLookup.java:205)
at
org.openide.util.lookup.MetaInfServicesLookup.beforeLookup(MetaInfServicesLookup.java:156)
at
org.openide.util.lookup.MetaInfServicesLookup.beforeLookupResult(MetaInfServicesLookup.java:135)
at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:483)
at org.openide.util.lookup.ProxyLookup$R.initResults(ProxyLookup.java:390)
at org.openide.util.lookup.ProxyLookup$R.myBeforeLookup(ProxyLookup.java:673)
at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:553)
at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:513)
at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:509)
at org.openide.util.Lookup.lookupAll(Lookup.java:312)
at org.netbeans.api.keyring.Keyring.provider(Keyring.java:89)
- locked <0xf0525f68> (a java.lang.Class for
org.netbeans.api.keyring.Keyring)
at org.netbeans.api.keyring.Keyring.readImpl(Keyring.java:105)
- locked <0xf0525f68> (a java.lang.Class for
org.netbeans.api.keyring.Keyring)
at org.netbeans.api.keyring.Keyring.access$100(Keyring.java:75)
at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:128)
at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:125)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)
"Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on
condition [0x2cd7a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xf05d6c10> (a
org.openide.util.RequestProcessor$RPFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
at
org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230)
at
org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87)
at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
- locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65)
at
sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
[jira] [Comment Edited] (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=16449647#comment-16449647
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 11:11 AM:
---
I need to stress that this issue is super critical, because it occurs
systematically and it makes NB IDE unusable. People will drop NB in favor for
other (more reliable?) IDE's which is pity and not to speak about the NB
platform applications... It is hard to defend and advertise the usage of NB in
your company when it just blocks right after startup...
was (Author: jmborer):
I need to stress that this issue is super critical, because it occurs
systematically and it makes NB IDE unusable. People will drop NB in favor for
other (more reliable?) IDE's which is pity and not to speak about the NB
platform applications... It is hard to defend NB in your company when it just
blocks right after startup...
> 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, 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
[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=16449647#comment-16449647
]
Jean-Marc Borer commented on NETBEANS-58:
-
I need to stress that this issue is super critical, because it occurs
systematically it makes NB IDE unusable. People will drop NB in favor for other
(more reliable) IDE's which is pity and not to speak about the NB platform
applications... It is hard to defend NB in your company when it just blocks
right after startup...
> 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, 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
>
[jira] [Comment Edited] (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=16449647#comment-16449647
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 11:10 AM:
---
I need to stress that this issue is super critical, because it occurs
systematically and it makes NB IDE unusable. People will drop NB in favor for
other (more reliable) IDE's which is pity and not to speak about the NB
platform applications... It is hard to defend NB in your company when it just
blocks right after startup...
was (Author: jmborer):
I need to stress that this issue is super critical, because it occurs
systematically it makes NB IDE unusable. People will drop NB in favor for other
(more reliable) IDE's which is pity and not to speak about the NB platform
applications... It is hard to defend NB in your company when it just blocks
right after startup...
> 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, 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}},
[jira] [Comment Edited] (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=16449647#comment-16449647
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 11:10 AM:
---
I need to stress that this issue is super critical, because it occurs
systematically and it makes NB IDE unusable. People will drop NB in favor for
other (more reliable?) IDE's which is pity and not to speak about the NB
platform applications... It is hard to defend NB in your company when it just
blocks right after startup...
was (Author: jmborer):
I need to stress that this issue is super critical, because it occurs
systematically and it makes NB IDE unusable. People will drop NB in favor for
other (more reliable) IDE's which is pity and not to speak about the NB
platform applications... It is hard to defend NB in your company when it just
blocks right after startup...
> 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, 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,
[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=16434018#comment-16434018
]
Jean-Marc Borer commented on NETBEANS-58:
-
I am not the man either for all this classloading fuss.:P
> 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, 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:
>
[jira] [Comment Edited] (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=16434018#comment-16434018
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/11/18 2:44 PM:
--
I am not the man either for all this classloading stuff. :P
was (Author: jmborer):
I am not the man either for all this classloading fuss.:P
> 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, 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.
[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=16432388#comment-16432388
]
Jean-Marc Borer commented on NETBEANS-58:
-
It is absolutely related to this topic: proxy authentication leads to HMI
deadlock at start up. I am 100% sure about it, I just reproduced it now with
JDK 1.8 162 and Netbeans 8.2. None of the workarounds mentioned here and at
https://netbeans.org/bugzilla/show_bug.cgi?id=262883 work. Neither the
ProxySelector V2 plugin
(http://plugins.netbeans.org/plugin/55258/proxyselector-v2) nor the Network
authenticator plugin
(http://plugins.netbeans.org/plugin/72976/network-authenticator) are fixing the
issue.
I am exactly in the same situation as all the people here waiting for a JDK (?)
fix.
> 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, 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
[jira] [Comment Edited] (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=16431984#comment-16431984
]
Jean-Marc Borer edited comment on NETBEANS-58 at 4/10/18 11:24 AM:
---
My comment is a backport of this bugzilla entry which is still true and
extremely annoying for me: https://netbeans.org/bugzilla/show_bug.cgi?id=262883
If I remember well, it appeared after upgrading to JDK 1.8 121, but not
absolutely sure, since we often had trouble with the corporate proxy and I
first thought it was my IT team that messed it up again and I had the network
proxy disabled. My trouble started when I wanted to check for IDE updates and
turned the proxy settings on again.
was (Author: jmborer):
My comment is a backport of this bugzilla entry which is still true and
extremely annoying for me: https://netbeans.org/bugzilla/show_bug.cgi?id=262883
If I remember well, it appeared after upgrading to JDK 1.8 121, but not
absolutely sure, since I we often had trouble with the corporate proxy and I
first thought it was my IT team that messed it up again and I had the network
proxy disabled. My trouble started when I wanted to check for IDE updates and
turned the proxy settings on again.
> 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, 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
[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=16431984#comment-16431984
]
Jean-Marc Borer commented on NETBEANS-58:
-
My comment is a backport of this bugzilla entry which is still true and
extremely annoying for me: https://netbeans.org/bugzilla/show_bug.cgi?id=262883
If I remember well, it appeared after upgrading to JDK 1.8 121, but not
absolutely sure, since I we often had trouble with the corporate proxy and I
first thought it was my IT team that messed it up again and I had the network
proxy disabled. My trouble started when I wanted to check for IDE updates and
turned the proxy settings on again.
> 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, 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
[jira] [Comment Edited] (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=16431958#comment-16431958 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/10/18 9:14 AM: -- We started running into this issue (Frozen stack trace with Java x64 8_162 and Netbeans 8.2 Win7x64) . No idea, why we never saw it before. Maybe someone changed something in the corporate proxy, but this is completely out of our reach. Once Netbeans is frozen, VisualVM can no longer properly interact with it. I managed to monitor NB with VisualVM before the freeze: thread view update. When NB freezes, thread view is also blocked, but I can still do a thread dump... VisualVM also suffers from this freezing bug as well as any NB platform application. No really astonishing since it based on NB platform. When we use "Manual Proxy Settings" from "No Proxy" it first works. Then we close the IDE and reopen it. It starts, but as soon as I try an action using the classloader such as opening a menu, it freezes completely. I managed to get a thread dump and the conclusion is similar to the ones here (I will attach it too). Unfortunately, https://bitbucket.org/phansson/netbeansproxy2 does not solve the issue at all. Same behaviour. After further analysis of my second thread [^nb-freeze-dump.txt] one can see that the issue lies in: 1) "Thread-8" takes the lock 0xc0d64370 in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thred "org.netbeans.api.keyring.Keyring" where it tries to get the lock on 0xc0d64370. Boom deadlock... This blocks the lock on 0xc0d64370 for every other thread including the AWT Event one. Workaround #1 doesn't work. The only solution currently is to work offline with "No proxy" or use a local proxy such as CNTLM, which then allows corporate proxy authentication and doesn't lead to this Keyring/Authenticator deadlock. [1] https://netbeans.org/bugzilla/show_bug.cgi?id=262883 [2] http://cntlm.sourceforge.net/ was (Author: jmborer): We started running into this issue (Frozen stack trace with Java x64 8_162 and Netbeans 8.2 Win7x64) . No idea, why we never saw it before. Maybe someone changed something in the corporate proxy, but this is completely out of our reach. Once Netbeans is frozen, VisualVM can no longer properly interact with it. I managed to monitor NB with VisualVM before the freeze: thread view update. When NB freezes, thread view is also blocked, but I can still do a thread dump... VisualVM also suffers from this freezing bug as well as any NB platform application. No really astonishing since it based on NB platform. When we use "Manual Proxy Settings" from "No Proxy" it first works. Then we close the IDE and reopen it. It starts, but as soon as I try an action using the classloader such as opening a menu, it freezes completely. I managed to get a thread dump and the conclusion is similar to the ones here (I will attach it too). Unfortunately, https://bitbucket.org/phansson/netbeansproxy2 does not solve the issue at all. Same behaviour. The only solution currently is to work offline with "No proxy" or use a local proxy such as CNTLM, which then allows corporate proxy authentication and doesn't lead to this Keyring/Authenticator deadlock. After further analysis of my second thread [^nb-freeze-dump.txt] one can see that the issue lies in: 1) "Thread-8" takes the lock 0xc0d64370 in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thred "org.netbeans.api.keyring.Keyring" where it tries to get the lock on 0xc0d64370. Boom deadlock... This blocks the lock on 0xc0d64370 for every other thread including the AWT Event one. [1] https://netbeans.org/bugzilla/show_bug.cgi?id=262883 [2] http://cntlm.sourceforge.net/ > 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, nb-freeze-dump.txt, > netbeans.txt > > > When any network operation is performed, such as attempting to
[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
]
Jean-Marc Borer updated NETBEANS-58:
Priority: Critical (was: Major)
> 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, 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}} will allow the JRE to obtain
[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=16431958#comment-16431958 ] Jean-Marc Borer commented on NETBEANS-58: - We started running into this issue (Frozen stack trace with Java x64 8_162 and Netbeans 8.2 Win7x64) . No idea, why we never saw it before. Maybe someone changed something in the corporate proxy, but this is completely out of our reach. Once Netbeans is frozen, VisualVM can no longer properly interact with it. I managed to monitor NB with VisualVM before the freeze: thread view update. When NB freezes, thread view is also blocked, but I can still do a thread dump... VisualVM also suffers from this freezing bug as well as any NB platform application. No really astonishing since it based on NB platform. When we use "Manual Proxy Settings" from "No Proxy" it first works. Then we close the IDE and reopen it. It starts, but as soon as I try an action using the classloader such as opening a menu, it freezes completely. I managed to get a thread dump and the conclusion is similar to the ones here (I will attach it too). Unfortunately, https://bitbucket.org/phansson/netbeansproxy2 does not solve the issue at all. Same behaviour. The only solution currently is to work offline with "No proxy" or use a local proxy such as CNTLM, which then allows corporate proxy authentication and doesn't lead to this Keyring/Authenticator deadlock. After further analysis of my second thread [^nb-freeze-dump.txt] one can see that the issue lies in: 1) "Thread-8" takes the lock 0xc0d64370 in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thred "org.netbeans.api.keyring.Keyring" where it tries to get the lock on 0xc0d64370. Boom deadlock... This blocks the lock on 0xc0d64370 for every other thread including the AWT Event one. [1] https://netbeans.org/bugzilla/show_bug.cgi?id=262883 [2] http://cntlm.sourceforge.net/ > 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: Major > Attachments: NETBEANS-58-workaround1.diff, 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.
[jira] [Updated] (NETBEANS-635) Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Borer updated NETBEANS-635:
-
Description:
When running tests with surefire 2.19.1, to see the stacktrace, make sure the
plugin is configured as following:
{code:java}
org.apache.maven.plugins
maven-surefire-plugin
2.19.1
false
{code}
Then you will see the stacktraces in the output. Even though they are
recognized as being hyperlinks, when you click on them, nothing happens and in
the status bar of Netbeans it says that the source file cannot be found.
This works perfectly with surefire 2.18.1. Something changed between these
versions.
Related topics:
[1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
[2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
[3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
> Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2
>Reporter: Jean-Marc Borer
>Priority: Major
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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] [Created] (NETBEANS-635) Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
Jean-Marc Borer created NETBEANS-635: Summary: Surefire 2.19.1 stacktrace hyperlinks don't work with Maven Key: NETBEANS-635 URL: https://issues.apache.org/jira/browse/NETBEANS-635 Project: NetBeans Issue Type: Bug Components: projects - Maven Affects Versions: 8.2 Reporter: Jean-Marc Borer -- 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
