February 2016 - jbosstools-issues

[JBoss JIRA] (JBIDE-21764) Duplicates of environment variables should be forbidden

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21764?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich reassigned JBIDE-21764: --------------------------------------------- Assignee: Viacheslav Kabanovich > Duplicates of environment variables should be forbidden > ------------------------------------------------------- > > Key: JBIDE-21764 > URL: https://issues.jboss.org/browse/JBIDE-21764 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.CR1 > Reporter: Marián Labuda > Assignee: Viacheslav Kabanovich > Labels: docker, openshift_v3 > Fix For: 4.4.0.Alpha1 > > > On 2nd wizard page of Deploy docker image is a table containing env. variables passed to OpenShift deployment config when docker image is deployed. Currently it is allowed to create duplicates of environment variables (more variables with same name), but only the last one is processed = it is passed to deployment config. E.g. I created env. vars. envvar1=val1 and envvar1=val2, but in deployment config only val2 is located. We should forbidden created duplicates of environment variables with same name. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-21764) Duplicates of environment variables should be forbidden

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21764?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich updated JBIDE-21764: ------------------------------------------ Fix Version/s: 4.4.0.Alpha1 > Duplicates of environment variables should be forbidden > ------------------------------------------------------- > > Key: JBIDE-21764 > URL: https://issues.jboss.org/browse/JBIDE-21764 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.CR1 > Reporter: Marián Labuda > Assignee: Viacheslav Kabanovich > Labels: docker, openshift_v3 > Fix For: 4.4.0.Alpha1 > > > On 2nd wizard page of Deploy docker image is a table containing env. variables passed to OpenShift deployment config when docker image is deployed. Currently it is allowed to create duplicates of environment variables (more variables with same name), but only the last one is processed = it is passed to deployment config. E.g. I created env. vars. envvar1=val1 and envvar1=val2, but in deployment config only val2 is located. We should forbidden created duplicates of environment variables with same name. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-21764) Duplicates of environment variables should be forbidden

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21764?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich updated JBIDE-21764: ------------------------------------------ Fix Version/s: (was: 4.4.x) > Duplicates of environment variables should be forbidden > ------------------------------------------------------- > > Key: JBIDE-21764 > URL: https://issues.jboss.org/browse/JBIDE-21764 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.CR1 > Reporter: Marián Labuda > Assignee: Viacheslav Kabanovich > Labels: docker, openshift_v3 > Fix For: 4.4.0.Alpha1 > > > On 2nd wizard page of Deploy docker image is a table containing env. variables passed to OpenShift deployment config when docker image is deployed. Currently it is allowed to create duplicates of environment variables (more variables with same name), but only the last one is processed = it is passed to deployment config. E.g. I created env. vars. envvar1=val1 and envvar1=val2, but in deployment config only val2 is located. We should forbidden created duplicates of environment variables with same name. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-21626) Pod is not created when docker image is deployed to OpenShift

by Jeff Cantrill (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21626?page=com.atlassian.jira.plugi... ] Jeff Cantrill commented on JBIDE-21626: --------------------------------------- [~fbricon] [~adietish][~maxandersen] These changes I think smooth out the experience. It allows for * Creating resources even when we are unable to access the metadata. User must provide at least a service port * The repo/username/image will be referenced in the ImageStream There are no guarantees you will see a pod spin up for this deployment. This will ONLY happen if the server can pull the image. If the repo is not defined, normal docker semantics apply which is it tries dockerhub. The only variance to this is if the server docker registry is configured to default someplace else. > Pod is not created when docker image is deployed to OpenShift > ------------------------------------------------------------- > > Key: JBIDE-21626 > URL: https://issues.jboss.org/browse/JBIDE-21626 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.CR1 > Reporter: Marián Labuda > Assignee: Jeff Cantrill > Priority: Critical > Labels: openshift_v3 > Fix For: 4.3.1.CR1 > > > When deploying a docker image to OpenShift via oc binary, pod where the image is supposed to run is created, together with service and router. But when deploying a docker image to OpenShift via OpenShift tools, no pod is created, only service and router. When using cli, pod is created later (what I noticed, there is different pull policy between creating from cli with "oc new-app docker-image" and creating from IDE). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-21732) Server Adapter: Improve routing selection group in New OpenShift Server adapter wizard

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21732?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich edited comment on JBIDE-21732 at 2/25/16 5:14 PM: ------------------------------------------------------------------------ Following XChat discussion, pull request is updated according to screenshots with "Advanced >>" button. In Eclipse Project input, combo is replaced with text widget with content assist and validation. was (Author: scabanovich): Following XChat discussion, pull request is updated according to screenshots with "Advanced >>" button. > Server Adapter: Improve routing selection group in New OpenShift Server adapter wizard > -------------------------------------------------------------------------------------- > > Key: JBIDE-21732 > URL: https://issues.jboss.org/browse/JBIDE-21732 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.3.1.CR1 > Reporter: Marián Labuda > Labels: openshift_v3, server_adapter > Attachments: default_route_os3.gliffy, EnhancedRouteGroup.png, NewServer_Advanced.png, NewServer_Advanced_Expanded.png, use-default-git-clone-destination.png > > > Currently there is a group called "Default Route" and there is a selection of a routing and checkbox for it. See attached diagram for proposed layout. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-21626) Pod is not created when docker image is deployed to OpenShift

by Jeff Cantrill (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21626?page=com.atlassian.jira.plugi... ] Jeff Cantrill edited comment on JBIDE-21626 at 2/25/16 5:14 PM: ---------------------------------------------------------------- [~fbricon] [~adietish] [~maxandersen] These changes I think smooth out the experience. It allows for * Creating resources even when we are unable to access the metadata. User must provide at least a service port * The repo/username/image will be referenced in the ImageStream There are no guarantees you will see a pod spin up for this deployment. This will ONLY happen if the server can pull the image. If the repo is not defined, normal docker semantics apply which is it tries dockerhub. The only variance to this is if the server docker registry is configured to default someplace else. was (Author: jcantrill): [~fbricon] [~adietish][~maxandersen] These changes I think smooth out the experience. It allows for * Creating resources even when we are unable to access the metadata. User must provide at least a service port * The repo/username/image will be referenced in the ImageStream There are no guarantees you will see a pod spin up for this deployment. This will ONLY happen if the server can pull the image. If the repo is not defined, normal docker semantics apply which is it tries dockerhub. The only variance to this is if the server docker registry is configured to default someplace else. > Pod is not created when docker image is deployed to OpenShift > ------------------------------------------------------------- > > Key: JBIDE-21626 > URL: https://issues.jboss.org/browse/JBIDE-21626 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.CR1 > Reporter: Marián Labuda > Assignee: Jeff Cantrill > Priority: Critical > Labels: openshift_v3 > Fix For: 4.3.1.CR1 > > > When deploying a docker image to OpenShift via oc binary, pod where the image is supposed to run is created, together with service and router. But when deploying a docker image to OpenShift via OpenShift tools, no pod is created, only service and router. When using cli, pod is created later (what I noticed, there is different pull policy between creating from cli with "oc new-app docker-image" and creating from IDE). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-21626) Pod is not created when docker image is deployed to OpenShift

by Jeff Cantrill (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21626?page=com.atlassian.jira.plugi... ] Jeff Cantrill updated JBIDE-21626: ---------------------------------- Git Pull Request: https://github.com/jbosstools/jbosstools-openshift/pull/956, https://github.com/openshift/openshift-restclient-java/pull/118, https://github.com/jbosstools/jbosstools-openshift/pull/984 (was: https://github.com/jbosstools/jbosstools-openshift/pull/956, https://github.com/openshift/openshift-restclient-java/pull/118) > Pod is not created when docker image is deployed to OpenShift > ------------------------------------------------------------- > > Key: JBIDE-21626 > URL: https://issues.jboss.org/browse/JBIDE-21626 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.CR1 > Reporter: Marián Labuda > Assignee: Jeff Cantrill > Priority: Critical > Labels: openshift_v3 > Fix For: 4.3.1.CR1 > > > When deploying a docker image to OpenShift via oc binary, pod where the image is supposed to run is created, together with service and router. But when deploying a docker image to OpenShift via OpenShift tools, no pod is created, only service and router. When using cli, pod is created later (what I noticed, there is different pull policy between creating from cli with "oc new-app docker-image" and creating from IDE). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-21742) Secure storage of OpenShift 3 token does not work

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21742?page=com.atlassian.jira.plugi... ] Fred Bricon reassigned JBIDE-21742: ----------------------------------- Assignee: Viacheslav Kabanovich Resolution: Done I couldn't reproduce the problem exactly, but I have a very similar issue with the OSX Keyring integration in my dev environment. The dialog showed up as expected and I believe it's as good as it can get. Applied in master / 4.3.x. [~mlabuda], please test it ASAP so we can rollback if necessary. > Secure storage of OpenShift 3 token does not work > ------------------------------------------------- > > Key: JBIDE-21742 > URL: https://issues.jboss.org/browse/JBIDE-21742 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.CR1 > Reporter: Marián Labuda > Assignee: Viacheslav Kabanovich > Labels: connection, openshift_v3, security_domain > Fix For: 4.3.1.CR1 > > Attachments: SecureStorageAccessFailure.png > > > When I have already user secure storage in another session (password is set) and I fill in valid token and check checkbox to store token in secure storage, confirmation dialog of secure storage is shown upon hitting Finish button. Upon filling invalid secure storage password for first time, dialog is invoked again to enter password. After second filling of invalid password for secure storage, it looks like it passed - no other prompt nor error dialog (just in error log see stack trace) and even in Connection dialog (opened via Edit context menu item on the connection) is checkbox for secure storage checked, what is wrong, because it is not stored (checked secure storage preference page and its content and also after restart of eclipse it was not stored). > {code} > org.jboss.tools.openshift.internal.common.core.security.SecureStoreException: Could not store value token: iQKo-5jRkMeaegCi3mljsFsAXhNaogmzwaKeaQNUAxc > at org.jboss.tools.openshift.internal.common.core.security.SecureStore.store(SecureStore.java:104) > at org.jboss.tools.openshift.internal.common.core.security.SecureStore.put(SecureStore.java:57) > at org.jboss.tools.openshift.core.connection.Connection.saveOrClear(Connection.java:187) > at org.jboss.tools.openshift.core.connection.Connection.save(Connection.java:159) > at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:207) > at org.jboss.tools.openshift.core.connection.Connection.retryList(Connection.java:424) > at org.jboss.tools.openshift.core.connection.Connection.getResources(Connection.java:368) > at org.jboss.tools.openshift.core.connection.Connection.getResources(Connection.java:355) > at org.jboss.tools.openshift.internal.ui.models.OpenShiftProjectCache.getProjectsFor(OpenShiftProjectCache.java:60) > at org.jboss.tools.openshift.internal.ui.explorer.OpenShiftExplorerContentProvider.getChildrenFor(OpenShiftExplorerContentProvider.java:95) > at org.jboss.tools.openshift.internal.common.ui.explorer.BaseExplorerContentProvider$1.run(BaseExplorerContentProvider.java:167) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) > Caused by: org.eclipse.equinox.security.storage.StorageException: No password provided. > at org.eclipse.equinox.internal.security.storage.SecurePreferencesRoot.getModulePassword(SecurePreferencesRoot.java:304) > at org.eclipse.equinox.internal.security.storage.SecurePreferencesRoot.getPassword(SecurePreferencesRoot.java:224) > at org.eclipse.equinox.internal.security.storage.SecurePreferences.put(SecurePreferences.java:224) > at org.eclipse.equinox.internal.security.storage.SecurePreferencesWrapper.put(SecurePreferencesWrapper.java:110) > at org.jboss.tools.openshift.internal.common.core.security.SecureStore.store(SecureStore.java:102) > ... 11 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-21771) Simplest java project is imported sometimes as JDT, sometimes not.

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21771?page=com.atlassian.jira.plugi... ] Alexey Kazakov reassigned JBIDE-21771: -------------------------------------- Assignee: Mickael Istria > Simplest java project is imported sometimes as JDT, sometimes not. > ------------------------------------------------------------------ > > Key: JBIDE-21771 > URL: https://issues.jboss.org/browse/JBIDE-21771 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: easymport > Affects Versions: 4.3.1.CR1 > Reporter: Radim Hopp > Assignee: Mickael Istria > Attachments: PlainJavaProject > > > Importing simplest java project (in attachment) gets sometimes imported as "Java, JDT" and sometimes only as "Java". I am not able to provide exact steps to reproduce, as it seems to do that randomly. > Looking at http://git.eclipse.org/c/e4/org.eclipse.e4.ui.git/tree/bundles/org.eclips..., project should be detected as JDT, in case ".classpath" is found in the project. Couldn't be the issue the order of executing configurators? Like when Java configurator is called first, it creates .classpath and then JDT configurator is called and it sees the .classpath file. When the order is opposite, JDT is not configured, because .classpath is not there yet? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-21754) Server adapter wizard: "Eclipse project" and "Source path" fields are redundant

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21754?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-21754: ------------------------------------------ we discussed to move "source path" and "Pod Deployment Path" to an collapsible "Advanced" section > Server adapter wizard: "Eclipse project" and "Source path" fields are redundant > ------------------------------------------------------------------------------- > > Key: JBIDE-21754 > URL: https://issues.jboss.org/browse/JBIDE-21754 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.3.1.Beta2 > Reporter: Xavier Coulon > Labels: openshift_v3, server_adapter_wizard > Fix For: 4.3.1.CR1 > > > One of the Server Adapter wizard page prompts the user for an {{Eclipse project}} and a {{Source path}}, but that second field seems redundant and more confusing than anything. Could it be removed ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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 February 2016