[JBoss JIRA] (JBIDE-22609) Provided wrong credentials, CDK server adapter says "started" even though it is not.
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22609?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22609:
--------------------------------
Sprint: devex #117 July 2016
> Provided wrong credentials, CDK server adapter says "started" even though it is not.
> ------------------------------------------------------------------------------------
>
> Key: JBIDE-22609
> URL: https://issues.jboss.org/browse/JBIDE-22609
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.0.Final
> Environment: Devstudio 10.0.0.GA (B33), CDK 2.1.RC4, Windows 10
> Reporter: Radim Hopp
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.4.x
>
>
> When CDK startup fails when it is provided wrong credentials (it fails on vagrant-registration), CDK server adapter sets its state to "started" and OS3 connection is created (even though OS3 is not running in vagrant) with some weird IP (10.0.2.15). Also error pops up saying "The CDK VM is up and running, but OpenShift is unreachable at url https://10.0.2.15:8443/healthz/ready". I really don't know where this IP comes from. I was able to reproduce it on Fedora using libvirt box and the IP was something like (192.168.x.x)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22608) Support scenario when cdk is stopped from cli and then in devstudio
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22608?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22608:
--------------------------------
Sprint: devex #117 July 2016
> Support scenario when cdk is stopped from cli and then in devstudio
> -------------------------------------------------------------------
>
> Key: JBIDE-22608
> URL: https://issues.jboss.org/browse/JBIDE-22608
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdk
> Affects Versions: 4.4.0.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> Assume your cdk is started and it's shown as started in devstudio, now what if you stop cdk from cli for whatever reason? Currently the tooling can't handle such situation.
> If you then try to stop cdk in devstudio, you get an error pop-up:
> Server Container Development Environment failed to stop.
> And the console will just say:
> ==> default: VM not created. Moving on...
> But most importantly, the server adapter will stay in the Started state.
> We should probably support this scenario - it's quite likely that it will happen to users.
> Right now there are several ways out of this situation:
> a) Start cdk from cli again and everything will probably work as expected
> b) Restart your IDE
> So I suggest we improve the tooling in such a way that when you stop cdk, it will be able to detect that it's actually not running and just change the state to Stopped. It may be still ok to pop up the error saying it failed to stop. But at least you can now start it again from the IDE.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22635) Deprecate / Remove the Server Log View
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22635?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22635:
--------------------------------
Sprint: devex #117 July 2016
> Deprecate / Remove the Server Log View
> --------------------------------------
>
> Key: JBIDE-22635
> URL: https://issues.jboss.org/browse/JBIDE-22635
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.4.1.AM1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
>
> Deprecate and remove the Server Log View.
> The Server Log View was originally designed to allow a custom "Error Log" to be filled with information that wasn't just "errors" but more like tracing what the server adapter was doing.
> In it's original form, it held all status warnings and errors, and users never saw them. Eventually, we started also sending the status objects to the official Error Log, so users may see them. Once that happened, the Server Log view became completely redundant. It's only benefits were that it occasionally over-logged stuff that wasn't appropriate to send to the main error log... but it's API / extension points were kinda ugly, and it overall isn't very useful any longer.
> Also, other server adapters have requested we remove the action at least, for their server types, since they never use the Server Log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-21744) cdk-created docker connection can have wrong name if you have multiple cdk server adapters
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21744?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-21744:
--------------------------------
Sprint: devex #117 July 2016 (was: devex #116 June 2016)
> cdk-created docker connection can have wrong name if you have multiple cdk server adapters
> ------------------------------------------------------------------------------------------
>
> Key: JBIDE-21744
> URL: https://issues.jboss.org/browse/JBIDE-21744
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.3.1.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.x
>
>
> I noticed that if I have two cdk server adapters, start the first one, stop it, start the second, then docker explorer will only show a connection of the first server name, not the second.
> This is probably because the connection will stay there after the first server start and on second server start, the tooling only checks if the docker host url matches. If it does, it will just reuse it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-19738) Failed runtime download offers no error message
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19738?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-19738:
--------------------------------
Sprint: devex #117 July 2016 (was: devex #116 June 2016)
> Failed runtime download offers no error message
> -----------------------------------------------
>
> Key: JBIDE-19738
> URL: https://issues.jboss.org/browse/JBIDE-19738
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.2.3.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Minor
> Fix For: 4.4.x
>
>
> While verifying JBIDE-19571 the runtime download failed and there was no error whatsoever. The download of FSW 6.0 almost started, but after a few seconds on the progress bar an error window showed up for a moment and then disappeared again and the download window was gone, too. After this, there was no error in the error view or the workspace log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-21745) Unable to download EAP 7 Beta runtime using username without "@redhat.com"
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21745?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-21745:
--------------------------------
Sprint: devex #117 July 2016 (was: devex #116 June 2016)
> Unable to download EAP 7 Beta runtime using username without "@redhat.com"
> --------------------------------------------------------------------------
>
> Key: JBIDE-21745
> URL: https://issues.jboss.org/browse/JBIDE-21745
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.3.0.Final, 4.3.1.CR1
> Environment: JBDS 9.1.0.CR1, JBDS 9.0.0.GA
> Reporter: Radim Hopp
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.4.x
>
> Attachments: rh-developer-credentials.png
>
>
> Trying to download EAP 7 Beta using login without "@redhat.com" fails on license agreement page.
> Instead of license agreement being displayed, just message saying "It is no longer possible to accept terms and conditions in the wizard. Please, use following link instead!" is shown. Given link redirects to Red Hat Developers portal login. After successful login, message is shown:
> {noformat}
> You Entered All Necessary Information
> Thank you for filling all necessary information. Now you can go back to Eclipse and retry your download of /jboss-eap-7.0.0.Beta.zip.
> {noformat}
> But even after that I'm unable to download that runtime with the same credentials.
> Using login with "@redhat.com" I'm able to download the runtime.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22578) Publishing sometimes recursively deletes parent to deploy directory
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22578?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22578:
--------------------------------
Sprint: devex #117 July 2016 (was: devex #116 June 2016)
> Publishing sometimes recursively deletes parent to deploy directory
> -------------------------------------------------------------------
>
> Key: JBIDE-22578
> URL: https://issues.jboss.org/browse/JBIDE-22578
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.3.1.Final
> Environment: Eclipse Mars.2 Release (4.5.2)
> Java 1.8.0_91
> Windows 7 64-bit
> JBoss EAP 6.4.0
> Reporter: Daniel Atallah
> Assignee: Martin Malina
> Priority: Blocker
> Fix For: 4.4.1.AM1
>
> Attachments: jboss_deployment.jpg, jboss_tools.20160630.stdout.log, servers.xml
>
>
> For a number of weeks we've had a number of occurrences where a eclipse workspace will get corrupted due to the deletion of all files in it.
> It seems to have started happening at the time we updated to the 4.3.1 JBoss Tools from the 4.3.0 JBoss Tools.
> We've been able to track the process doing the deleting to the Eclipse process by using Sysinternals Process Monitor tool (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx).
> Our workspaces are structured as follows:
> {noformat}
> WORKSPACEROOT=$DEVROOT\workspacename
> # Custom deploy folder (as specified in the "Deployment" settings for the configured "Red Hat JBoss Enterprise Application Platform 6.1+") Server
> $WORKSPACEROOT\deploy
> # Version Control (Mercurial) working directory containing various Eclipse projects that get published to the Server by the tooling
> $WORKSPACEROOT\src
> # value specified as a "jboss.server.data.dir" property in the Server launch configuration VM arguments
> $WORKSPACEROOT/server/data
> # value specified as a "jboss.server.temp.dir" property in the Server launch configuration VM arguments
> $WORKSPACEROOT/server/tmp
> {noformat}
> The Server is configured to "Automatically publish when resources change".
> What we're seeing is that occasionally when the Server is running and the Mercurial working copy receives updates, the Incremental Publishing that results from these updates somehow tries to recursively delete $WORKSPACEROOT.
> The eclipse log includes the following:
> {noformat}
> !ENTRY org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795
> !MESSAGE Problems occurred refreshing resources
> !SUBENTRY 1 org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795
> !MESSAGE Problem finding next change, code: 5
> !ENTRY org.jboss.ide.eclipse.as.core 4 1644298244 2016-06-07 16:06:09.207
> !MESSAGE Incremental publish failed for module $MODULENAME
> !SUBENTRY 1 org.jboss.ide.eclipse.as.wtp.core 4 1644298251 2016-06-07 16:06:09.207
> !MESSAGE Could not delete $WORKSPACEROOT. May be locked by another process.
> {noformat}
> Any idea what might be happening?
> Is there some debug logging we can enable to get better visibility to what's going on?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months