[JBoss JIRA] (JBIDE-26306) Server adapter: deleting server adapter after project causes NPE
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26306?page=com.atlassian.jira.plugi... ]
Andre Dietisheim resolved JBIDE-26306.
--------------------------------------
Assignee: Andre Dietisheim
Resolution: Duplicate Issue
> Server adapter: deleting server adapter after project causes NPE
> -----------------------------------------------------------------
>
> Key: JBIDE-26306
> URL: https://issues.jboss.org/browse/JBIDE-26306
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.9.0.AM1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: server_adapter
> Fix For: 4.9.0.AM3
>
> Attachments: image-2018-08-14-11-57-17-905.png
>
>
> steps:
> # ASSERT: have an application running in OpenShift that you created via the eap70-basic-s2i template
> # ASSERT: have the project imported into workspace, have the server adapter created for it
> # EXEC: delete the project in workspace
> # EXEC: delete the server (have it stopped before being deleted - the checkbox checked for this sake)
> Result:
> Error dialog reports an NPE
> !image-2018-08-14-11-57-17-905.png!
> {code}
> java.lang.NullPointerException
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftShutdownController.updateProject(OpenShiftShutdownController.java:71)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftShutdownController.stop(OpenShiftShutdownController.java:58)
> at org.jboss.ide.eclipse.as.wtp.core.server.behavior.ControllableServerBehavior.stop(ControllableServerBehavior.java:255)
> at org.eclipse.wst.server.core.internal.Server.stopImpl2(Server.java:3698)
> at org.eclipse.wst.server.core.internal.Server.stopImpl(Server.java:3655)
> at org.eclipse.wst.server.core.internal.Server$StopJob.run(Server.java:413)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-26306) Server adapter: deleting server adapter after project causes NPE
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26306?page=com.atlassian.jira.plugi... ]
Andre Dietisheim closed JBIDE-26306.
------------------------------------
> Server adapter: deleting server adapter after project causes NPE
> -----------------------------------------------------------------
>
> Key: JBIDE-26306
> URL: https://issues.jboss.org/browse/JBIDE-26306
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.9.0.AM1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: server_adapter
> Fix For: 4.9.0.AM3
>
> Attachments: image-2018-08-14-11-57-17-905.png
>
>
> steps:
> # ASSERT: have an application running in OpenShift that you created via the eap70-basic-s2i template
> # ASSERT: have the project imported into workspace, have the server adapter created for it
> # EXEC: delete the project in workspace
> # EXEC: delete the server (have it stopped before being deleted - the checkbox checked for this sake)
> Result:
> Error dialog reports an NPE
> !image-2018-08-14-11-57-17-905.png!
> {code}
> java.lang.NullPointerException
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftShutdownController.updateProject(OpenShiftShutdownController.java:71)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftShutdownController.stop(OpenShiftShutdownController.java:58)
> at org.jboss.ide.eclipse.as.wtp.core.server.behavior.ControllableServerBehavior.stop(ControllableServerBehavior.java:255)
> at org.eclipse.wst.server.core.internal.Server.stopImpl2(Server.java:3698)
> at org.eclipse.wst.server.core.internal.Server.stopImpl(Server.java:3655)
> at org.eclipse.wst.server.core.internal.Server$StopJob.run(Server.java:413)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-26306) Server adapter: deleting server adapter after project causes NPE
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26306?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-26306:
------------------------------------------
[~jeffmaury] nicely spotted. Yes this definitely is a duplicate of JBIDE-26327. Closing as duplicate.
> Server adapter: deleting server adapter after project causes NPE
> -----------------------------------------------------------------
>
> Key: JBIDE-26306
> URL: https://issues.jboss.org/browse/JBIDE-26306
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.9.0.AM1
> Reporter: Andre Dietisheim
> Labels: server_adapter
> Fix For: 4.9.0.AM3
>
> Attachments: image-2018-08-14-11-57-17-905.png
>
>
> steps:
> # ASSERT: have an application running in OpenShift that you created via the eap70-basic-s2i template
> # ASSERT: have the project imported into workspace, have the server adapter created for it
> # EXEC: delete the project in workspace
> # EXEC: delete the server (have it stopped before being deleted - the checkbox checked for this sake)
> Result:
> Error dialog reports an NPE
> !image-2018-08-14-11-57-17-905.png!
> {code}
> java.lang.NullPointerException
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftShutdownController.updateProject(OpenShiftShutdownController.java:71)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftShutdownController.stop(OpenShiftShutdownController.java:58)
> at org.jboss.ide.eclipse.as.wtp.core.server.behavior.ControllableServerBehavior.stop(ControllableServerBehavior.java:255)
> at org.eclipse.wst.server.core.internal.Server.stopImpl2(Server.java:3698)
> at org.eclipse.wst.server.core.internal.Server.stopImpl(Server.java:3655)
> at org.eclipse.wst.server.core.internal.Server$StopJob.run(Server.java:413)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-26306) Server adapter: deleting server adapter after project causes NPE
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26306?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-26306:
-------------------------------------
Fix Version/s: 4.9.0.AM3
(was: 4.9.x)
> Server adapter: deleting server adapter after project causes NPE
> -----------------------------------------------------------------
>
> Key: JBIDE-26306
> URL: https://issues.jboss.org/browse/JBIDE-26306
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.9.0.AM1
> Reporter: Andre Dietisheim
> Labels: server_adapter
> Fix For: 4.9.0.AM3
>
> Attachments: image-2018-08-14-11-57-17-905.png
>
>
> steps:
> # ASSERT: have an application running in OpenShift that you created via the eap70-basic-s2i template
> # ASSERT: have the project imported into workspace, have the server adapter created for it
> # EXEC: delete the project in workspace
> # EXEC: delete the server (have it stopped before being deleted - the checkbox checked for this sake)
> Result:
> Error dialog reports an NPE
> !image-2018-08-14-11-57-17-905.png!
> {code}
> java.lang.NullPointerException
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftShutdownController.updateProject(OpenShiftShutdownController.java:71)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftShutdownController.stop(OpenShiftShutdownController.java:58)
> at org.jboss.ide.eclipse.as.wtp.core.server.behavior.ControllableServerBehavior.stop(ControllableServerBehavior.java:255)
> at org.eclipse.wst.server.core.internal.Server.stopImpl2(Server.java:3698)
> at org.eclipse.wst.server.core.internal.Server.stopImpl(Server.java:3655)
> at org.eclipse.wst.server.core.internal.Server$StopJob.run(Server.java:413)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ERT-667) [GTK2] Remove GTK 2.x support [EBZ#530841]
by Friendly Jira Robot (JIRA)
Friendly Jira Robot created ERT-667:
---------------------------------------
Summary: [GTK2] Remove GTK 2.x support [EBZ#530841]
Key: ERT-667
URL: https://issues.jboss.org/browse/ERT-667
Project: Eclipse Release Train
Issue Type: Task
Components: Platform
Reporter: Friendly Jira Robot
TL;DR: Gtk 2.x bugs are not investigated anymore. Please submit Gtk3* show stoppers to Bug 527444 instead.
Reason:
Gtk 2.x is getting old and a number of underlying libraries are getting changes which are not tested with it anymore. The fact that it relies on Webkit 1.x API which is not shipped with newer Linux distributions makes the Browser component on GTK 2.x useless quite often. This makes it increasingly difficult to maintain it. Almost all new Linux distributions provide Gtk 3.x with Webkit 2.
As such effort is focused on improving Gtk 3.x and Wayland support.
Gtk 2.x-only bugs are set to have Priority of P5, indicating that bugs exist, but will not be investigated by committers. Patches welcome though!
FAQ:
1) Question: "I rely on Gtk 2.x because of bug XYZ in Gtk 3x".
Answer: Focus is on resolving any 'gtk3' show stoppers that you may be experiencing. If you have a bug that stops you from moving to Gtk 3.x, please mention it in the gtk3 show stopper tracker (below) and we will do our best to address the bug in question:
Bug 527444 [GTK3] Umbrella bug for GTK3 showstoppers
https://bugs.eclipse.org/bugs/show_bug.cgi?id=527444
2) Question: "Gtk3 doesn't look proper on my gtk3 theme"
Answer: Unfortunatley we don't have the man power to test/fix eclipse against every Gtk 3.x theme out there. Further a lot of the Gtk 3.x themes are pretty buggy, such bugs are out of our control.
'Adwaita' (light & dark) which is the default Gtk3/Gnome theme is the recommended choice for best results.
Note, Gtk underwent a lot of theming changes. Gtk 3.22 is currently the most stable for themes.
Note, 'Oxygen-gtk' theme engine is know to cause a lot of breakage and Gtk currently doesn't support it either.
This bug is in place to provide information on Gtk2 status.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ERT-666) Improve JDT Indexer performance for method reference lookups
by Roland Grunberg (JIRA)
[ https://issues.jboss.org/browse/ERT-666?page=com.atlassian.jira.plugin.sy... ]
Roland Grunberg updated ERT-666:
--------------------------------
Description:
Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer.
One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format.
The methodRef category table currently stores :
(symbol, number of arguments) -> document numbers (classfiles)
toString/0 -> [1, 4, 5, 25]
The proposal would change this to :
(symbol, symbol's classname, classname) -> document numbers (classfiles)
toString/0/java.lang.Object -> [1, 4, 5, 25]
Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference.
(/) Make the patch mostly correct
(/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString()
(?) Detect method references even in dead code (this is supported by existing indexer)
(?) More complicated performance test against the Eclipse Platform itself for java.lang.Object.toString()
(?) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() )
was:
Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer.
One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format.
The methodRef category table currently stores :
(symbol, number of arguments) -> document numbers (classfiles)
toString/0 -> [1, 4, 5, 25]
The proposal would change this to :
(symbol, symbol's classname, classname) -> document numbers (classfiles)
toString/0/java.lang.Object -> [1, 4, 5, 25]
Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference.
(/) Make the patch mostly correct
(/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString()
(?) Detect method references even in dead code (this is supported by existing indexer)
(?) Detect method references in comments (annotations) (this is supported by existing indexer)
(?) More complicated performance test against the Eclipse Platform itself for java.lang.Object.toString()
(?) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() )
> Improve JDT Indexer performance for method reference lookups
> ------------------------------------------------------------
>
> Key: ERT-666
> URL: https://issues.jboss.org/browse/ERT-666
> Project: Eclipse Release Train
> Issue Type: Task
> Reporter: Roland Grunberg
> Assignee: Roland Grunberg
>
> Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer.
> One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format.
> The methodRef category table currently stores :
> (symbol, number of arguments) -> document numbers (classfiles)
> toString/0 -> [1, 4, 5, 25]
> The proposal would change this to :
> (symbol, symbol's classname, classname) -> document numbers (classfiles)
> toString/0/java.lang.Object -> [1, 4, 5, 25]
> Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference.
> (/) Make the patch mostly correct
> (/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString()
> (?) Detect method references even in dead code (this is supported by existing indexer)
> (?) More complicated performance test against the Eclipse Platform itself for java.lang.Object.toString()
> (?) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() )
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months