[JBoss JIRA] (JBIDE-21733) Docker connection does not work with CDK build 2016-02-19
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21733?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-21733:
-----------------------------------
Priority: Critical (was: Major)
> Docker connection does not work with CDK build 2016-02-19
> ---------------------------------------------------------
>
> Key: JBIDE-21733
> URL: https://issues.jboss.org/browse/JBIDE-21733
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.3.1.Beta2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.3.1.CR1
>
>
> Today I tried cdk build 2016-02-19 in JBDS 9.1.0.Beta2:
> When I started this from JBDS, it worked, but the Docker connection could not be established.
> It gives me this error:
> {code}
> 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
> 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:779)
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.getImages(DockerConnection.java:742)
> at org.eclipse.linuxtools.internal.docker.ui.views.DockerImagesContentProvider$1$1.run(DockerImagesContentProvider.java:71)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
> at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4024)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3700)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:694)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:606)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> 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:497)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
> 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:772)
> ... 27 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)
> ... 29 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:449)
> 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}
> To be sure, I also tried the other cdk from https://github.com/redhat-developer-tooling/openshift-vagrant and that worked. Then I tried back the official cdk and that didn't work.
> I'm pretty sure that this worked for me with the previous build. Not sure what changed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21293) CDK start timed out due to slow image download
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21293?page=com.atlassian.jira.plugi... ]
Alexey Kazakov resolved JBIDE-21293.
------------------------------------
Resolution: Duplicate Issue
Let's resolve this as a duplicate of JBIDE-21622
We could open a separate upstream issue though if we want to improve this mechanism so users are asked if they want to wait longer if the start was timed out.
> CDK start timed out due to slow image download
> ----------------------------------------------
>
> Key: JBIDE-21293
> URL: https://issues.jboss.org/browse/JBIDE-21293
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.3.1.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.1.CR1
>
>
> I set up a CDK server using https://github.com/redhat-developer-tooling/openshift-vagrant .
> Then I tried to start the server for the first time. Of course this will take quite long as it needs to download the VM image first. I was on a very fast connection, but it still only went around 1 MB/s. So the startup took longer than the default timeout of 450 s. The result was that the startup timed out in the middle followed by an attempted shutdown by the tooling which failed. So in the end I ended up with the running box, but with two unwanted errors.
> I'm not sure what we can do here. Perhaps just increase the timeout to something bigger? Even better would be if could detect that a download is in progress so it will take longer, but I don't think the current mechanism is capable of anything like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21293) CDK start timed out due to slow image download
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21293?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-21293:
-----------------------------------
Fix Version/s: 4.4.x
(was: 4.3.1.CR1)
> CDK start timed out due to slow image download
> ----------------------------------------------
>
> Key: JBIDE-21293
> URL: https://issues.jboss.org/browse/JBIDE-21293
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.3.1.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.1.CR1
>
>
> I set up a CDK server using https://github.com/redhat-developer-tooling/openshift-vagrant .
> Then I tried to start the server for the first time. Of course this will take quite long as it needs to download the VM image first. I was on a very fast connection, but it still only went around 1 MB/s. So the startup took longer than the default timeout of 450 s. The result was that the startup timed out in the middle followed by an attempted shutdown by the tooling which failed. So in the end I ended up with the running box, but with two unwanted errors.
> I'm not sure what we can do here. Perhaps just increase the timeout to something bigger? Even better would be if could detect that a download is in progress so it will take longer, but I don't think the current mechanism is capable of anything like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21293) CDK start timed out due to slow image download
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21293?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-21293:
-----------------------------------
Fix Version/s: 4.3.1.CR1
(was: 4.4.x)
> CDK start timed out due to slow image download
> ----------------------------------------------
>
> Key: JBIDE-21293
> URL: https://issues.jboss.org/browse/JBIDE-21293
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.3.1.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.1.CR1
>
>
> I set up a CDK server using https://github.com/redhat-developer-tooling/openshift-vagrant .
> Then I tried to start the server for the first time. Of course this will take quite long as it needs to download the VM image first. I was on a very fast connection, but it still only went around 1 MB/s. So the startup took longer than the default timeout of 450 s. The result was that the startup timed out in the middle followed by an attempted shutdown by the tooling which failed. So in the end I ended up with the running box, but with two unwanted errors.
> I'm not sure what we can do here. Perhaps just increase the timeout to something bigger? Even better would be if could detect that a download is in progress so it will take longer, but I don't think the current mechanism is capable of anything like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21460) Server adapter: NPE at Show In Web Browser if connection is not connected
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21460?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-21460:
-------------------------------------
Merged the jbt-server pull.
> Server adapter: NPE at Show In Web Browser if connection is not connected
> -------------------------------------------------------------------------
>
> Key: JBIDE-21460
> URL: https://issues.jboss.org/browse/JBIDE-21460
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Labels: openshift_v3, server_adapter
> Fix For: 4.3.1.CR1
>
> Attachments: not-authorized-error.png
>
>
> 1. Create an OpenShift connection, do not choose save password/token.
> 2. Create an OpenShift server for the connection.
> 3. Close Eclipse with Server view active
> 4. Restart Eclipse, select Server view.
> 5. In context menu of the server, select Show In Web Browser.
> 6. 'Sign In' dialog appears, select cancel.
> (Note: First time when I got it, dialog did not appear, later I could not repeat steps that would skip the dialog.)
> 7. Failure: NPE while executing getWelcomePageUrl().
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21290) CDK 2 is detected as version 1.0
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21290?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-21290:
--------------------------------
Fix Version/s: 4.3.2.Final
(was: 4.3.1.CR1)
> CDK 2 is detected as version 1.0
> --------------------------------
>
> Key: JBIDE-21290
> URL: https://issues.jboss.org/browse/JBIDE-21290
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, runtime-detection, upstream
> Affects Versions: 4.3.1.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Minor
> Fix For: 4.4.0.Alpha1, 4.3.2.Final
>
> Attachments: cdk-runtime-detection.png, Screenshot 2016-01-07 09.16.12.png
>
>
> When you detect CDK using runtime detection, it will show you the name cdk-v2 which clearly shows it's version 2 (this is actually just based on the folder it seems). But the Version column says Version 1.0.
> !cdk-runtime-detection.png!
> Could we change it to version 2?
> I know that this probably doesn't have any meaning right now - I noticed there is no runtime anymore, so the version is nowhere to be seen once you create the cdk server adapter. But it would still be nicer to show the correct version if possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21716) Don't re-prompt for password
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21716?page=com.atlassian.jira.plugi... ]
Alexey Kazakov reassigned JBIDE-21716:
--------------------------------------
Assignee: Rob Stryker
cc: [~dgolovin]
It doesn't seem to be double for JBDS 9.1.0.CR1. Let's see what we can do after the 9.1.0 release.
> Don't re-prompt for password
> ----------------------------
>
> Key: JBIDE-21716
> URL: https://issues.jboss.org/browse/JBIDE-21716
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdk
> Reporter: Pete Muir
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.4.0.Alpha1
>
>
> Having installed JBDS and CDK from the installer, and entered your password there, you get re-prompted for your password for the customer portal. This is a poor user experience.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBDS-3602) Error Reporting doesnt work since we do not set eclipse.buildid
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3602?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov reassigned JBDS-3602:
------------------------------------
Assignee: Denis Golovin
Assigning to [~dgolovin] since [~nickboldt] is on PTO this week.
> Error Reporting doesnt work since we do not set eclipse.buildid
> ---------------------------------------------------------------
>
> Key: JBDS-3602
> URL: https://issues.jboss.org/browse/JBDS-3602
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: aeri
> Affects Versions: 9.1.0.CR1
> Environment: JBDS 9.1.0.CR1-v20160222-0232-B335
> JBT Nightly (2016-02-22)
> both contains the same version of aeri plugins
> Reporter: Rastislav Wagner
> Assignee: Denis Golovin
> Priority: Blocker
> Fix For: 9.1.0.CR1
>
>
> So I tied to evoke error reporting dialog with the following scenario:
> 1. import Java EE Web Project from central
> 2. right click in Project Explorer -> refactor -> rename
> 3. change name, hit OK which will result in errors from org.hibernate stuff
> In case of JBDS no error reporting dialog is shown, works in JBT
> I also tried org.eclipse stuff:
> 1. open Properties view
> 2. create JPA Project (File -> New -> Other... JPA Project)
> 3. open persistence.xml which will result in NPE from org.eclipse stuff
> And again in no error reporting dialog in case of JBDS but works in JBT
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBDS-3601) No splash screen during JBDS 8.x startup on Windows
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3601?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov commented on JBDS-3601:
--------------------------------------
This is probably an upstream (Eclipse & Windows) problem. Not sure we can do anything about it if it works fine on JBDS 9.0.
> No splash screen during JBDS 8.x startup on Windows
> ---------------------------------------------------
>
> Key: JBDS-3601
> URL: https://issues.jboss.org/browse/JBDS-3601
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer, upstream
> Affects Versions: 8.1.0.GA
> Environment: WIndows 7 (RHEV VM) + Oracle JDK 7
> Reporter: Lyle Wang
> Fix For: 8.x
>
>
> After a typical installation, when trying to startup JBDS 8 / 8.1, there is no splash screen (and loading progress bar) before showing up the JBDS main window.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month