[JBoss JIRA] (JBIDE-21847) Start port forwarding button is disabled after starting and stopping it
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21847?page=com.atlassian.jira.plugi... ]
Marián Labuda commented on JBIDE-21847:
---------------------------------------
Ok here is the scenario with free ports
ASSERT: Have an OpenShift 3 application
EXEC: Open Port Forwarding wizard.
EXEC: Check usage of free ports checkbox.
EXEC: Start port forwarding.
EXEC: Stop port forwarding.
ASSERT: Start All button is enabled and Stop All button is disabled.
EXEC: Uncheck usage of free ports checkbox.
EXEC: Start port forwarding.
EXEC: Stop port forwarding.
RESULT: Start All and Stop All buttons are disabled.
> Start port forwarding button is disabled after starting and stopping it
> -----------------------------------------------------------------------
>
> Key: JBIDE-21847
> URL: https://issues.jboss.org/browse/JBIDE-21847
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Labels: openshift_v3, port_forwarding_wizard
> Fix For: 4.3.1.CR1
>
>
> In Port Forwarding wizard when I start port forwarding, then stop it, the button Start All is disabled and it is not possible to start port forwarding again. Well, both buttons after starting and stopping are disabled, only OK is enabled.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21847) Start port forwarding button is disabled after starting and stopping it
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21847?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-21847:
-----------------------------------------------
But, still after unchecking free ports, Start All button became enabled?
> Start port forwarding button is disabled after starting and stopping it
> -----------------------------------------------------------------------
>
> Key: JBIDE-21847
> URL: https://issues.jboss.org/browse/JBIDE-21847
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Labels: openshift_v3, port_forwarding_wizard
> Fix For: 4.3.1.CR1
>
>
> In Port Forwarding wizard when I start port forwarding, then stop it, the button Start All is disabled and it is not possible to start port forwarding again. Well, both buttons after starting and stopping are disabled, only OK is enabled.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21847) Start port forwarding button is disabled after starting and stopping it
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21847?page=com.atlassian.jira.plugi... ]
Marián Labuda commented on JBIDE-21847:
---------------------------------------
None of them is "in use".
When usage of free ports is checked and port forwarding started and stopped, it is working as expected = Start All is enabled again.
After unchecking the checkbox in the end of previous step and starting and stopping port forwarding, it is still broken and it behaves like described in this issue.
There is no entry in error log.
> Start port forwarding button is disabled after starting and stopping it
> -----------------------------------------------------------------------
>
> Key: JBIDE-21847
> URL: https://issues.jboss.org/browse/JBIDE-21847
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Labels: openshift_v3, port_forwarding_wizard
> Fix For: 4.3.1.CR1
>
>
> In Port Forwarding wizard when I start port forwarding, then stop it, the button Start All is disabled and it is not possible to start port forwarding again. Well, both buttons after starting and stopping are disabled, only OK is enabled.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21840) Checkbox to save password in Secure Storage is not checked when password is stored
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21840?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-21840:
-----------------------------------------------
[~adietish], please take a look at the pull request.
Basic and Auth got there own checkboxes bound to rememberPassword and rememberToken respectively, with visibility dependent on selection.
I made change to Connection.save(), which needs double check.
> Checkbox to save password in Secure Storage is not checked when password is stored
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-21840
> URL: https://issues.jboss.org/browse/JBIDE-21840
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Labels: connection_wizard, openshift_v3
> Fix For: 4.3.1.CR1
>
>
> In OpenShift connection wizard there is a checkbox to store password/token in secure storage. If I choose on an existing OpenShift 3 connection with basic authentication to store password in secure storage, technically it is stored and visible on Secure Storage preference page, but in Connection wizard it is not visible. Upon next opening of the Edit Connection wizard, checkbox is unchecked although password is checked.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBDS-3618) Progress does not reflect actual amount of work done
by Jan Richter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3618?page=com.atlassian.jira.plugin.... ]
Jan Richter commented on JBDS-3618:
-----------------------------------
The point here is the way it is implemented now is counting on a time estimate for the download. That's a static number and it looks fairly overshot. The downloads usually end in the first 20% of the progress, because the initial estimate just sets the maximum to some (high) value. So then the progress bars just keep moving slowly towards 99% no matter their state until they are set to complete.
> Progress does not reflect actual amount of work done
> ----------------------------------------------------
>
> Key: JBDS-3618
> URL: https://issues.jboss.org/browse/JBDS-3618
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Reporter: Jan Richter
> Assignee: Joshua Wilson
> Priority: Minor
> Labels: havoc, ui
>
> It seems the current way the progress tracking is implemented is simply by giving an initial time estimate for each component. The progress bars then just count down the supplied time with no relation to the actual progress achieved.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21845) Docker connection does not work with CDK build 2016-03-09
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21845?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-21845:
---------------------------------------
[~fbricon], yes, I destroyed and removed the box before trying this new build. But I got a word from CDK QE now that there is a known issue with this build. Ondra Ptak said the certificate was for a different IP. And it worked for him with Docker Tools but not with docker client CLI. But that's not exactly what I'm seeing. There should be a new build today.
> Docker connection does not work with CDK build 2016-03-09
> ---------------------------------------------------------
>
> Key: JBIDE-21845
> URL: https://issues.jboss.org/browse/JBIDE-21845
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.3.1.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> Today I tried cdk build 2016-03-09 in JBDS 9.1.0.CR1 (build from 2 days ago).
> I start cdk, the docker connection is created, but it doesn't work:
> {code}
> org.eclipse.linuxtools.docker.core.DockerException: com.spotify.docker.client.DockerException: java.util.concurrent.ExecutionException: javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.listImages(DockerConnection.java:787)
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.getImages(DockerConnection.java:750)
> at org.eclipse.linuxtools.internal.docker.ui.views.DockerExplorerContentProvider$5.run(DockerExplorerContentProvider.java:241)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: com.spotify.docker.client.DockerException: java.util.concurrent.ExecutionException: javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> at com.spotify.docker.client.DefaultDockerClient.propagate(DefaultDockerClient.java:1141)
> at com.spotify.docker.client.DefaultDockerClient.request(DefaultDockerClient.java:1072)
> at com.spotify.docker.client.DefaultDockerClient.listImages(DefaultDockerClient.java:354)
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.listImages(DockerConnection.java:780)
> ... 3 more
> Caused by: java.util.concurrent.ExecutionException: javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> at jersey.repackaged.com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)
> at jersey.repackaged.com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:293)
> at jersey.repackaged.com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> at com.spotify.docker.client.DefaultDockerClient.request(DefaultDockerClient.java:1070)
> ... 5 more
> Caused by: javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> at org.glassfish.jersey.apache.connector.ApacheConnector.apply(ApacheConnector.java:517)
> at org.glassfish.jersey.apache.connector.ApacheConnector$1.run(ApacheConnector.java:527)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at jersey.repackaged.com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:293)
> at jersey.repackaged.com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:49)
> at jersey.repackaged.com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:45)
> at org.glassfish.jersey.apache.connector.ApacheConnector.apply(ApacheConnector.java:523)
> at org.glassfish.jersey.client.ClientRuntime$1.run(ClientRuntime.java:169)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
> at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:320)
> at org.glassfish.jersey.client.ClientRuntime$2.run(ClientRuntime.java:201)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1506)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:290)
> at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:259)
> at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:125)
> at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:319)
> at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)
> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:72)
> at org.glassfish.jersey.apache.connector.ApacheConnector.apply(ApacheConnector.java:469)
> ... 20 more
> Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:352)
> at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:260)
> at sun.security.validator.Validator.validate(Validator.java:260)
> at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1488)
> ... 39 more
> Caused by: java.security.cert.CertPathValidatorException: signature check failed
> at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135)
> at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:219)
> at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140)
> at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79)
> at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
> at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:347)
> ... 45 more
> Caused by: java.security.SignatureException: Signature does not match.
> at sun.security.x509.X509CertImpl.verify(X509CertImpl.java:424)
> at sun.security.provider.certpath.BasicChecker.verifySignature(BasicChecker.java:166)
> at sun.security.provider.certpath.BasicChecker.check(BasicChecker.java:147)
> at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
> ... 50 more
> {code}
> This looks similar to JBIDE-21733 . But in this case it doesn't work even from terminal:
> {code}
> $ eval "$(vagrant service-manager env docker)"
> $ docker ps
> An error occurred trying to connect: Get https://10.1.2.2:2376/v1.20/containers/json: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "example.com")
> {code}
> So yeah, this does not seem like the problem is on our site, but let's keep this JIRA for tracking anyway.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21840) Checkbox to save password in Secure Storage is not checked when password is stored
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21840?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich edited comment on JBIDE-21840 at 3/10/16 1:40 AM:
------------------------------------------------------------------------
Attempt to access secure storage in order to set this checkbox may invoke dialog asking password for secure storage (at least if it has not yet appeared in the current session). It will be very annoying for a user who _have not_ selected to save password before.
Added: no, if user have not stored password, request to secure storage does not invoke this dialog. And it works as requested for Openshift 2. So, it is a bug. I checked that in Connection.loadPassword() the password is loaded and flag rememberPassword is set to true, but somehow it does not find its way to the checkbox.
was (Author: scabanovich):
Attempt to access secure storage in order to set this checkbox may invoke dialog asking password for secure storage (at least if it has not yet appeared in the current session). It will be very annoying for a user who _have not_ selected to save password before.
> Checkbox to save password in Secure Storage is not checked when password is stored
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-21840
> URL: https://issues.jboss.org/browse/JBIDE-21840
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Labels: connection_wizard, openshift_v3
> Fix For: 4.3.1.CR1
>
>
> In OpenShift connection wizard there is a checkbox to store password/token in secure storage. If I choose on an existing OpenShift 3 connection with basic authentication to store password in secure storage, technically it is stored and visible on Secure Storage preference page, but in Connection wizard it is not visible. Upon next opening of the Edit Connection wizard, checkbox is unchecked although password is checked.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-20747) install-grinder returns a blue ball but fails to install 5 plugins due to missing capability &/or package
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20747?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-20747:
----------------------------------------
We already have tests that verify that jetty/livereload is working. There is no need to create new ones (parsing log and so on), we could simply run the existing ones. The missing thing is an "acceptance test suite" that we could install in an existing IDE to validate it works enough for us to trust it.
Overall, all that is the same issue as running integration-test on provisioned application automatically. I believe [~psrna] already does that on QE's Jenkins instance; maybe we could clone one job to the common Jenkins one. (Overall, it's really important that the whole team starts using a single Jenkins at some point, for more visibility of existing jobs).
> install-grinder returns a blue ball but fails to install 5 plugins due to missing capability &/or package
> ---------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-20747
> URL: https://issues.jboss.org/browse/JBIDE-20747
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Priority: Critical
> Fix For: 4.4.0.Alpha1
>
> Attachments: features.txt, plugins.txt
>
>
> This happened in http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
> {code}
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.browsersim.eclipse [1120]
> Unresolved requirement: Require-Bundle: org.jboss.tools.browsersim.ui; bundle-version="3.7.0"
> -> Bundle-SymbolicName: org.jboss.tools.browsersim.ui; bundle-version="3.7.0.CR1-v20150901-2111-B229"; singleton:="true"
> org.jboss.tools.browsersim.ui [1122]
> Unresolved requirement: Require-Bundle: org.eclipse.jetty.websocket.server; bundle-version="[9.0.0,10.0.0)"
> -> Bundle-SymbolicName: org.eclipse.jetty.websocket.server; bundle-version="9.2.13.v20150730"
> org.eclipse.jetty.websocket.server [555]
> Unresolved requirement: Require-Capability: osgi.extender; filter:="(osgi.extender=osgi.serviceloader.registrar)"
> Unresolved requirement: Import-Package: org.eclipse.jetty.websocket.servlet; version="[9.0.0,10.0.0)"
> -> Export-Package: org.eclipse.jetty.websocket.servlet; bundle-symbolic-name="org.eclipse.jetty.websocket.servlet"; bundle-version="9.2.13.v20150730"; version="9.2.13"
> org.eclipse.jetty.websocket.servlet [556]
> Unresolved requirement: Require-Capability: osgi.serviceloader; filter:="(osgi.serviceloader=org.eclipse.jetty.websocket.servlet.WebSocketServletFactory)"; cardinality:="multiple"
> -> Provide-Capability: osgi.serviceloader; osgi.serviceloader="org.eclipse.jetty.websocket.servlet.WebSocketServletFactory"
> {code}
> -- http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
> Similar problems for other IUs:
> {code}
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.cordovasim.eclipse [1163]
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.feedhenry.ui [1166]
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.livereload.core [1221]
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.livereload.ui [1222]
> {code}
> But the job was successful!
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month