[JBoss JIRA] (JBIDE-17615) When runtime download asks to reenter credentials, it will not accept them even if valid
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17615?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-17615:
---------------------------------------
I wanted to try the use case I previously mentioned:
1. User starts the runtime download dialog, enters correct credentials, moves to license
2. User changes his password on jboss.org
3. User carries on in the dialog to actually start the download - now he will probably be asked to correct his credentials
But for that I need to change my password at jboss.org, which currently doesn't work for me - reported here: ORG-3476
So I will revisit this later.
> When runtime download asks to reenter credentials, it will not accept them even if valid
> ----------------------------------------------------------------------------------------
>
> Key: JBIDE-17615
> URL: https://issues.jboss.org/browse/JBIDE-17615
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Beta2
> Environment: JBDS 8.0.0.Beta2c B130
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.1.AM2
>
>
> I was playing around JBIDE-17601 - that JIRA is about the bug that JBoss.org credentials were not validated when you went through new archetype from central -> Download & Install. So you could enter anything and it would let you carry on. But once the real download is about to start, you will get a popup to enter the credentials again (since the downloader needs the correct password). Even if you now enter the correct credentials, it will ask you 2 more times and then fail on Incorrect password.
> Yes, this will be less likely to happen once JBIDE-17601 is fixed. But I suppose that the popup is in place exactly for the situation when the password needs to be corrected, so it should work, right?
> There may still be a valid use case to hit this issue (although a very rare case):
> 1. User starts the runtime download dialog, enters correct credentials, moves to license
> 2. User changes his password on jboss.org
> 3. User carries on in the dialog to actually start the download - now he will probably be asked to correct his credentials
> So in my opinion, if we already have a mechanism to ask for credentials again, then it should work. If you say this is not needed, then why even allow the popup?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22699) BrowserUtilTest.testCreateBrowser failure
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22699?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-22699:
--------------------------------
Sprint: (was: devex #117 July 2016)
> BrowserUtilTest.testCreateBrowser failure
> -----------------------------------------
>
> Key: JBIDE-22699
> URL: https://issues.jboss.org/browse/JBIDE-22699
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.4.1.AM1
> Reporter: Alexey Kazakov
> Assignee: Alexey Kazakov
> Fix For: 4.4.1.AM2
>
>
> org.jboss.tools.foundation.ui.test.BrowserUtilTest.testCreateBrowser
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at org.jboss.tools.foundation.ui.test.BrowserUtilTest.testCreateBrowser(BrowserUtilTest.java:32)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22699) BrowserUtilTest.testCreateBrowser failure
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22699?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-22699:
--------------------------------
Sprint: devex #118 July 2017
> BrowserUtilTest.testCreateBrowser failure
> -----------------------------------------
>
> Key: JBIDE-22699
> URL: https://issues.jboss.org/browse/JBIDE-22699
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.4.1.AM1
> Reporter: Alexey Kazakov
> Assignee: Alexey Kazakov
> Fix For: 4.4.1.AM2
>
>
> org.jboss.tools.foundation.ui.test.BrowserUtilTest.testCreateBrowser
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at org.jboss.tools.foundation.ui.test.BrowserUtilTest.testCreateBrowser(BrowserUtilTest.java:32)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22079) Import wizard: Error when import a project already existing in workspace
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22079?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-22079:
-------------------------------------
Fix Version/s: 4.4.1.AM3
(was: 4.4.x)
> Import wizard: Error when import a project already existing in workspace
> ------------------------------------------------------------------------
>
> Key: JBIDE-22079
> URL: https://issues.jboss.org/browse/JBIDE-22079
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Labels: import_wizard, openshift_v3
> Fix For: 4.4.1.AM3
>
> Attachments: import-error.png
>
>
> When I am creating a new OpenShift application using an existing repo, or at least project in workspace, it throws an error upon application creation completion. This is a bit of pain, because even I have an existing git repo and checked the checkbox in Import Wizard to reuse it, it tries to import project then, but it fails. But the existing project is still usable to use it for a new OpenShift 3 server adapter and upon start of the adapter, local changes are published to OpenShift. This issue is just about error. Maybe we could display a dialog that such a project already exists in workspace and let user to choose to replace it by the one being imported or keep it as it is (if user know that the project in workspace is the correct one and he/she does not want to overwrite it and let local changes disappear).
> Error:
> {code}Could not import project from org.jboss.tools.openshift.internal.common.ui.application.importoperation.ImportFailedException: There was a maven related error that prevented us from importing the project. We encourage you to look into the pom in the cloned repository at /home/mlabuda/git/jboss-eap-quickstarts.
> One of the possible reasons is that there is already a project in your workspace that matches the maven name of the OpenShift application. You can then rename your workspace project and start over again.
> An exception stack trace is not available.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22079) Import wizard: Error when import a project already existing in workspace
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22079?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-22079:
------------------------------------------
merged into master
> Import wizard: Error when import a project already existing in workspace
> ------------------------------------------------------------------------
>
> Key: JBIDE-22079
> URL: https://issues.jboss.org/browse/JBIDE-22079
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Labels: import_wizard, openshift_v3
> Fix For: 4.4.x
>
> Attachments: import-error.png
>
>
> When I am creating a new OpenShift application using an existing repo, or at least project in workspace, it throws an error upon application creation completion. This is a bit of pain, because even I have an existing git repo and checked the checkbox in Import Wizard to reuse it, it tries to import project then, but it fails. But the existing project is still usable to use it for a new OpenShift 3 server adapter and upon start of the adapter, local changes are published to OpenShift. This issue is just about error. Maybe we could display a dialog that such a project already exists in workspace and let user to choose to replace it by the one being imported or keep it as it is (if user know that the project in workspace is the correct one and he/she does not want to overwrite it and let local changes disappear).
> Error:
> {code}Could not import project from org.jboss.tools.openshift.internal.common.ui.application.importoperation.ImportFailedException: There was a maven related error that prevented us from importing the project. We encourage you to look into the pom in the cloned repository at /home/mlabuda/git/jboss-eap-quickstarts.
> One of the possible reasons is that there is already a project in your workspace that matches the maven name of the OpenShift application. You can then rename your workspace project and start over again.
> An exception stack trace is not available.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22362) Server Adapter: Static changes done to nodejs application are not visible
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22362?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-22362:
-------------------------------------
Fix Version/s: 4.4.1.AM3
(was: 4.4.x)
> Server Adapter: Static changes done to nodejs application are not visible
> -------------------------------------------------------------------------
>
> Key: JBIDE-22362
> URL: https://issues.jboss.org/browse/JBIDE-22362
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Alpha2
> Reporter: Marián Labuda
> Assignee: Ilya Buziuk
> Priority: Critical
> Labels: openshift_v3, server_adapter
> Fix For: 4.4.1.AM3
>
>
> I am having an OpenShift application based either on nodejs-example or nodejs-mongodb-example template. Once application is up and running I create a new server adapter and perform changes in index.html. These changes are static and should be (?) immediately visible on OpenShift server, but they are not. I have checked whether changes were published, but rsync in console shows expected output also changes done manually on the server side to index.html are not visible in browser (even when cache overwritten is triggered - so there is no caching problem in browser). This seems to be upstream issues, but requires investigating.
> So far I have tried it on CDK OpenShift. It would be nice to test it on other OpenShift instances, also on templates using different base docker image.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months