May 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (ERT-201) Trying to run an image from DockerExplorerView says image needs pulling for a secondary tag [EBZ#493953]

by Jeff Johnston (JIRA)

[ https://issues.jboss.org/browse/ERT-201?page=com.atlassian.jira.plugin.sy... ] Jeff Johnston reassigned ERT-201: --------------------------------- Assignee: Jeff Johnston > Trying to run an image from DockerExplorerView says image needs pulling for a secondary tag [EBZ#493953] > -------------------------------------------------------------------------------------------------------- > > Key: ERT-201 > URL: https://issues.jboss.org/browse/ERT-201 > Project: Eclipse Release Train > Issue Type: Task > Components: Linux Tools > Reporter: Friendly Jira Robot > Assignee: Jeff Johnston > Labels: 5.0.0, Docker, bzira > Fix For: Neon (4.6) > > > Trying to run an image which has multiple tags picks the last tag listed in the DockerExplorerView node. The Run Image Wizard will only show the first in any list and thinks that the image is not pulled so issues a message about it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ERT-201) Trying to run an image from DockerExplorerView says image needs pulling for a secondary tag [EBZ#493953]

by Jeff Johnston (JIRA)

[ https://issues.jboss.org/browse/ERT-201?page=com.atlassian.jira.plugin.sy... ] Jeff Johnston resolved ERT-201. ------------------------------- Resolution: Done > Trying to run an image from DockerExplorerView says image needs pulling for a secondary tag [EBZ#493953] > -------------------------------------------------------------------------------------------------------- > > Key: ERT-201 > URL: https://issues.jboss.org/browse/ERT-201 > Project: Eclipse Release Train > Issue Type: Task > Components: Linux Tools > Reporter: Friendly Jira Robot > Assignee: Jeff Johnston > Labels: 5.0.0, Docker, bzira > Fix For: Neon (4.6) > > > Trying to run an image which has multiple tags picks the last tag listed in the DockerExplorerView node. The Run Image Wizard will only show the first in any list and thinks that the image is not pulled so issues a message about it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ERT-149) NullPointerException in ContainerInspectPropertySection$1.run (87) [EBZ#482255]

by Jeff Johnston (JIRA)

[ https://issues.jboss.org/browse/ERT-149?page=com.atlassian.jira.plugin.sy... ] Jeff Johnston resolved ERT-149. ------------------------------- Resolution: Done > NullPointerException in ContainerInspectPropertySection$1.run (87) [EBZ#482255] > ------------------------------------------------------------------------------- > > Key: ERT-149 > URL: https://issues.jboss.org/browse/ERT-149 > Project: Eclipse Release Train > Issue Type: Task > Components: Linux Tools > Reporter: Friendly Jira Robot > Labels: 4.2.1, Docker, bzira > Fix For: Neon (4.6) > > > The following incident was reported via the automated error reporting: > code: 2 > plugin: org.eclipse.core.jobs_3.7.0.v20150330-2103 > message: An internal error occurred during: "Loading Container info...". > fingerprint: 4cab8f71 > exception class: java.lang.NullPointerException > exception message: - > number of children: 0 > > java.lang.NullPointerException: null > at java.util.concurrent.ArrayBlockingQueue.checkNotNull(ArrayBlockingQueue.java:156) > at java.util.concurrent.ArrayBlockingQueue.offer(ArrayBlockingQueue.java:307) > at java.util.AbstractQueue.add(AbstractQueue.java:106) > at java.util.concurrent.ArrayBlockingQueue.add(ArrayBlockingQueue.java:294) > at org.eclipse.linuxtools.internal.docker.ui.views.ContainerInspectPropertySection$1.run(ContainerInspectPropertySection.java:87) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) > > > General Information: > reported-by: > anonymous-id: f3c5e82f-fde4-4965-8adb-898895cadd9a > eclipse-build-id: 4.5.1.M20150904-0015 > eclipse-product: org.eclipse.epp.package.jee.product > operating system: Windows7 6.1.0 (x86_64) - win32 > jre-version: pwa6470_27sr1-20140411_01 (SR1) > The following plug-ins were present on the execution stack (*): > 1. org.eclipse.core.jobs_3.7.0.v20150330-2103 > 2. org.eclipse.linuxtools.docker.ui_1.1.0.201509161915 > Please note that: > * Messages, stacktraces, and nested status objects may be shortened. > * Bug fields like status, resolution, and whiteboard are sent > back to reporters. > * The list of present bundles and their respective versions was > calculated by package naming heuristics. This may or may not reflect reality. > Other Resources: > * Report: https://dev.eclipse.org/recommenders/committers/confess/#/problems/55e1be... > * Manual: https://dev.eclipse.org/recommenders/community/confess/#/guide > Thank you for your assistance. > Your friendly error-reports-inbox. > This bug was created on behalf of xcoulon@xxxxxxxxxxxx. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ERT-149) NullPointerException in ContainerInspectPropertySection$1.run (87) [EBZ#482255]

by Jeff Johnston (JIRA)

[ https://issues.jboss.org/browse/ERT-149?page=com.atlassian.jira.plugin.sy... ] Jeff Johnston updated ERT-149: ------------------------------ Sprint: devex #115 May 2016 > NullPointerException in ContainerInspectPropertySection$1.run (87) [EBZ#482255] > ------------------------------------------------------------------------------- > > Key: ERT-149 > URL: https://issues.jboss.org/browse/ERT-149 > Project: Eclipse Release Train > Issue Type: Task > Components: Linux Tools > Reporter: Friendly Jira Robot > Labels: 4.2.1, Docker, bzira > Fix For: Neon (4.6) > > > The following incident was reported via the automated error reporting: > code: 2 > plugin: org.eclipse.core.jobs_3.7.0.v20150330-2103 > message: An internal error occurred during: "Loading Container info...". > fingerprint: 4cab8f71 > exception class: java.lang.NullPointerException > exception message: - > number of children: 0 > > java.lang.NullPointerException: null > at java.util.concurrent.ArrayBlockingQueue.checkNotNull(ArrayBlockingQueue.java:156) > at java.util.concurrent.ArrayBlockingQueue.offer(ArrayBlockingQueue.java:307) > at java.util.AbstractQueue.add(AbstractQueue.java:106) > at java.util.concurrent.ArrayBlockingQueue.add(ArrayBlockingQueue.java:294) > at org.eclipse.linuxtools.internal.docker.ui.views.ContainerInspectPropertySection$1.run(ContainerInspectPropertySection.java:87) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) > > > General Information: > reported-by: > anonymous-id: f3c5e82f-fde4-4965-8adb-898895cadd9a > eclipse-build-id: 4.5.1.M20150904-0015 > eclipse-product: org.eclipse.epp.package.jee.product > operating system: Windows7 6.1.0 (x86_64) - win32 > jre-version: pwa6470_27sr1-20140411_01 (SR1) > The following plug-ins were present on the execution stack (*): > 1. org.eclipse.core.jobs_3.7.0.v20150330-2103 > 2. org.eclipse.linuxtools.docker.ui_1.1.0.201509161915 > Please note that: > * Messages, stacktraces, and nested status objects may be shortened. > * Bug fields like status, resolution, and whiteboard are sent > back to reporters. > * The list of present bundles and their respective versions was > calculated by package naming heuristics. This may or may not reflect reality. > Other Resources: > * Report: https://dev.eclipse.org/recommenders/committers/confess/#/problems/55e1be... > * Manual: https://dev.eclipse.org/recommenders/community/confess/#/guide > Thank you for your assistance. > Your friendly error-reports-inbox. > This bug was created on behalf of xcoulon@xxxxxxxxxxxx. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ERT-170) Chromium Debug: Terminating V8 debugger process should also kill main(Node) process. [EBZ#491735]

by Ilya Buziuk (JIRA)

[ https://issues.jboss.org/browse/ERT-170?page=com.atlassian.jira.plugin.sy... ] Ilya Buziuk reassigned ERT-170: ------------------------------- Assignee: Ilya Buziuk > Chromium Debug: Terminating V8 debugger process should also kill main(Node) process. [EBZ#491735] > ------------------------------------------------------------------------------------------------- > > Key: ERT-170 > URL: https://issues.jboss.org/browse/ERT-170 > Project: Eclipse Release Train > Issue Type: Task > Components: JSDT > Reporter: Friendly Jira Robot > Assignee: Ilya Buziuk > Labels: Debug, bzira > > The normal scenario for starting a chomium debugger process includes both launching the main js runtime (Node), and also starting the V8 debugger process... > Users will expect the same when terminating (both are killed). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22426) Connection: authorization strategy is always overwritten (in the client) upon #isConnected

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22426?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-22426 at 5/25/16 5:18 PM: ------------------------------------------------------------------- these are internal changes and added tests and changes in the client library (OSJC-256). Nothing for QE to verify, closing was (Author: adietish): these are internal changes and added tests. Nothing for QE to verify, closing > Connection: authorization strategy is always overwritten (in the client) upon #isConnected > ------------------------------------------------------------------------------------------- > > Key: JBIDE-22426 > URL: https://issues.jboss.org/browse/JBIDE-22426 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Alpha3 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: connection, openshift_v3 > Fix For: 4.4.0.Alpha3 > > > The current implementation of Connection#isConnected() will always overwrite the authorization strategy in the client that it is using. This seems wrong given that #getResources, #createResource, #updateResource (and other methods) also set it but check if it already exists beforehand. Making sure that they dont overwrite an existing strategy. > {code:title=Connection#isConnected} > public boolean isConnected(IProgressMonitor monitor) { > client.setAuthorizationStrategy(getAuthorizationStrategy()); > try { > {code} > {code:title=Connection#createResource} > public <T extends IResource> T createResource(T resource) { > try { > if(client.getAuthorizationStrategy() == null) { > client.setAuthorizationStrategy(getAuthorizationStrategy()); > } > return client.create(resource); > {code} > A very likely side-effect of this is in Connection#ownsResource which compares clients (the one in the connection and the one attached to the given resource. The 2 clients are compared with the authorization strategy: > {code:title=com.openshift.internal.restclient.DefaultClient#equals} > @Override > public boolean equals(Object obj) { > ... > return ObjectUtils.equals(strategy, other.strategy); > {code} > the lookup for a connection for a given resource in ConnectionRegistryUtils#safeGetConnectionFor will therefore fail after a Connection#isConnected: > {code:title=ConnectionsRegistryUtil#safeGetConnectionFor(IResource)} > public static Connection safeGetConnectionFor(IResource resource) { > Collection<Connection> all = ConnectionsRegistrySingleton.getInstance().getAll(Connection.class); > for (Connection connection : all) { > if(connection.ownsResource(resource)) { > return connection; > } > } > return null; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22426) Connection: authorization strategy is always overwritten (in the client) upon #isConnected

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22426?page=com.atlassian.jira.plugi... ] Andre Dietisheim closed JBIDE-22426. ------------------------------------ Resolution: Done > Connection: authorization strategy is always overwritten (in the client) upon #isConnected > ------------------------------------------------------------------------------------------- > > Key: JBIDE-22426 > URL: https://issues.jboss.org/browse/JBIDE-22426 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Alpha3 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: connection, openshift_v3 > Fix For: 4.4.0.Alpha3 > > > The current implementation of Connection#isConnected() will always overwrite the authorization strategy in the client that it is using. This seems wrong given that #getResources, #createResource, #updateResource (and other methods) also set it but check if it already exists beforehand. Making sure that they dont overwrite an existing strategy. > {code:title=Connection#isConnected} > public boolean isConnected(IProgressMonitor monitor) { > client.setAuthorizationStrategy(getAuthorizationStrategy()); > try { > {code} > {code:title=Connection#createResource} > public <T extends IResource> T createResource(T resource) { > try { > if(client.getAuthorizationStrategy() == null) { > client.setAuthorizationStrategy(getAuthorizationStrategy()); > } > return client.create(resource); > {code} > A very likely side-effect of this is in Connection#ownsResource which compares clients (the one in the connection and the one attached to the given resource. The 2 clients are compared with the authorization strategy: > {code:title=com.openshift.internal.restclient.DefaultClient#equals} > @Override > public boolean equals(Object obj) { > ... > return ObjectUtils.equals(strategy, other.strategy); > {code} > the lookup for a connection for a given resource in ConnectionRegistryUtils#safeGetConnectionFor will therefore fail after a Connection#isConnected: > {code:title=ConnectionsRegistryUtil#safeGetConnectionFor(IResource)} > public static Connection safeGetConnectionFor(IResource resource) { > Collection<Connection> all = ConnectionsRegistrySingleton.getInstance().getAll(Connection.class); > for (Connection connection : all) { > if(connection.ownsResource(resource)) { > return connection; > } > } > return null; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22225) Debugging for node.js applications on Openshift

by Ilya Buziuk (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22225?page=com.atlassian.jira.plugi... ] Ilya Buziuk reassigned JBIDE-22225: ----------------------------------- Assignee: Ilya Buziuk > Debugging for node.js applications on Openshift > ----------------------------------------------- > > Key: JBIDE-22225 > URL: https://issues.jboss.org/browse/JBIDE-22225 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: javascript, openshift > Reporter: Gorkem Ercan > Assignee: Ilya Buziuk > Fix For: 4.4.x > > > We should be able to start and connect the new debugger to a node.js application running on Openshift. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22426) Connection: authorization strategy is always overwritten (in the client) upon #isConnected

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22426?page=com.atlassian.jira.plugi... ] Andre Dietisheim resolved JBIDE-22426. -------------------------------------- Resolution: Done > Connection: authorization strategy is always overwritten (in the client) upon #isConnected > ------------------------------------------------------------------------------------------- > > Key: JBIDE-22426 > URL: https://issues.jboss.org/browse/JBIDE-22426 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Alpha3 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: connection, openshift_v3 > Fix For: 4.4.0.Alpha3 > > > The current implementation of Connection#isConnected() will always overwrite the authorization strategy in the client that it is using. This seems wrong given that #getResources, #createResource, #updateResource (and other methods) also set it but check if it already exists beforehand. Making sure that they dont overwrite an existing strategy. > {code:title=Connection#isConnected} > public boolean isConnected(IProgressMonitor monitor) { > client.setAuthorizationStrategy(getAuthorizationStrategy()); > try { > {code} > {code:title=Connection#createResource} > public <T extends IResource> T createResource(T resource) { > try { > if(client.getAuthorizationStrategy() == null) { > client.setAuthorizationStrategy(getAuthorizationStrategy()); > } > return client.create(resource); > {code} > A very likely side-effect of this is in Connection#ownsResource which compares clients (the one in the connection and the one attached to the given resource. The 2 clients are compared with the authorization strategy: > {code:title=com.openshift.internal.restclient.DefaultClient#equals} > @Override > public boolean equals(Object obj) { > ... > return ObjectUtils.equals(strategy, other.strategy); > {code} > the lookup for a connection for a given resource in ConnectionRegistryUtils#safeGetConnectionFor will therefore fail after a Connection#isConnected: > {code:title=ConnectionsRegistryUtil#safeGetConnectionFor(IResource)} > public static Connection safeGetConnectionFor(IResource resource) { > Collection<Connection> all = ConnectionsRegistrySingleton.getInstance().getAll(Connection.class); > for (Connection connection : all) { > if(connection.ownsResource(resource)) { > return connection; > } > } > return null; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22426) Connection: authorization strategy is always overwritten (in the client) upon #isConnected

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22426?page=com.atlassian.jira.plugi... ] Andre Dietisheim closed JBIDE-22426. ------------------------------------ > Connection: authorization strategy is always overwritten (in the client) upon #isConnected > ------------------------------------------------------------------------------------------- > > Key: JBIDE-22426 > URL: https://issues.jboss.org/browse/JBIDE-22426 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Alpha3 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: connection, openshift_v3 > Fix For: 4.4.0.Alpha3 > > > The current implementation of Connection#isConnected() will always overwrite the authorization strategy in the client that it is using. This seems wrong given that #getResources, #createResource, #updateResource (and other methods) also set it but check if it already exists beforehand. Making sure that they dont overwrite an existing strategy. > {code:title=Connection#isConnected} > public boolean isConnected(IProgressMonitor monitor) { > client.setAuthorizationStrategy(getAuthorizationStrategy()); > try { > {code} > {code:title=Connection#createResource} > public <T extends IResource> T createResource(T resource) { > try { > if(client.getAuthorizationStrategy() == null) { > client.setAuthorizationStrategy(getAuthorizationStrategy()); > } > return client.create(resource); > {code} > A very likely side-effect of this is in Connection#ownsResource which compares clients (the one in the connection and the one attached to the given resource. The 2 clients are compared with the authorization strategy: > {code:title=com.openshift.internal.restclient.DefaultClient#equals} > @Override > public boolean equals(Object obj) { > ... > return ObjectUtils.equals(strategy, other.strategy); > {code} > the lookup for a connection for a given resource in ConnectionRegistryUtils#safeGetConnectionFor will therefore fail after a Connection#isConnected: > {code:title=ConnectionsRegistryUtil#safeGetConnectionFor(IResource)} > public static Connection safeGetConnectionFor(IResource resource) { > Collection<Connection> all = ConnectionsRegistrySingleton.getInstance().getAll(Connection.class); > for (Connection connection : all) { > if(connection.ownsResource(resource)) { > return connection; > } > } > return null; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues May 2016