[JBoss JIRA] (JBIDE-21832) CDK server adapter should you localhost host name by default
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21832?page=com.atlassian.jira.plugi... ]
Marián Labuda closed JBIDE-21832.
---------------------------------
Resolution: Duplicate Issue
[~mmalina] was faster. This is a duplicate of JBIDE-21831
> CDK server adapter should you localhost host name by default
> ------------------------------------------------------------
>
> Key: JBIDE-21832
> URL: https://issues.jboss.org/browse/JBIDE-21832
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
>
> In New Server wizard when I select CDK Server Adapter, the host name text widget contains value from previous selection. If previous selection was using a different host name than localhost, error validation mark is shown with message about not supported remote connections. It would be nice, if host name would be automatically set to localhost every time CDK Server Adapter is chosen, to let user continue through wizard. Otherwise it is necessary to fix it manually from a different host name to localhost.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21832) CDK server adapter should you localhost host name by default
by Marián Labuda (JIRA)
Marián Labuda created JBIDE-21832:
-------------------------------------
Summary: CDK server adapter should you localhost host name by default
Key: JBIDE-21832
URL: https://issues.jboss.org/browse/JBIDE-21832
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: cdk
Affects Versions: 4.3.1.CR1
Reporter: Marián Labuda
In New Server wizard when I select CDK Server Adapter, the host name text widget contains value from previous selection. If previous selection was using a different host name than localhost, error validation mark is shown with message about not supported remote connections. It would be nice, if host name would be automatically set to localhost every time CDK Server Adapter is chosen, to let user continue through wizard. Otherwise it is necessary to fix it manually from a different host name to localhost.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21831) Change host to localhost when cdk is selected in new server dialog
by Martin Malina (JIRA)
Martin Malina created JBIDE-21831:
-------------------------------------
Summary: Change host to localhost when cdk is selected in new server dialog
Key: JBIDE-21831
URL: https://issues.jboss.org/browse/JBIDE-21831
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: cdk
Affects Versions: 4.3.1.CR1
Reporter: Martin Malina
Assignee: Rob Stryker
When you open the new server dialog, select OpenShift 2, it will set host to openshift.redhat.com. When you then select cdk, it will complain that it only works on localhost. So the suggestion is to make it work the same way OpenShift adapters work and ensure that host is always changed to localhost when you select the cdk adapter.
This was spotted and brought up by [~mlabuda].
For reference, this is the JIRA where similar thing was discussed for OpenShift: JBIDE-20114
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21821) JBoss Developer Studio Marketplace Install Breaks Egit in Mars.2
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21821?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21821:
------------------------------------
Looks like the issue is in fact an incompatibility w/ jgit 4.0 and 4.1 -- both shouldn't be coinstalled. Your error log mentions both:
* org.eclipse.jgit 4.0.3.201509231615-r
* org.eclipse.jgit 4.1.1.201511131810-r
And for JBT, both are dropped to disk. But for JBDS, only 4.1.1 is installed.
The reason is that the JBT site doesn't include a neewer version of org.eclipse.egit.ui.importer, so you get the Mars.1 version, 4.0.0.201506090130-r, which requires jgit 4.0. So jgit 4.0.3 (from Mars.1) is also installed.
But in JBDS you DO get forced into installing the Mars.2 version, and end up with org.eclipse.egit.ui.importer 4.1.1.201511131810-r
--
So... the problem is that in JBT 4.3 (Mars) we still hardcode a link to the "latest" *released* JBT TP [1]. In JBT 4.4 (Neon) we removed this (JBIDE-21233) to avoid exactly this problem.
[1] http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/mars/ --> currently points at http://download.jboss.org/jbosstools/static/targetplatforms/jbosstoolstar... (which includes org.eclipse.egit.ui.importer 4.0.0.201506090130-r)
So... installation will continue to be a problem for JBT if you install from the snapshot site [2] which DOES NOT include the latest TP [3].
But if you use the JBT snapshot site which DOES include the latest TP [4], you should be fine because that will include the newer egit.ui.importer 4.1.1.
[2] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars/
[3] http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.5...
[4] http://download.jboss.org/jbosstools/mars/snapshots/updates/
> JBoss Developer Studio Marketplace Install Breaks Egit in Mars.2
> ----------------------------------------------------------------
>
> Key: JBIDE-21821
> URL: https://issues.jboss.org/browse/JBIDE-21821
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, marketplace
> Reporter: Thomas Mäder
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.3.1.CR1
>
> Attachments: FrameworkEvent ERROR.txt, jbt-error
>
>
> Installing Red Hat JBoss Developer Studio 9.0.0GA into a fresh Eclipse 4.5.2 (for Eclipse Committers) causes Egit to break.
> # Install Eclipse 4.5.2
> # In the Marketplace, search for "jboss developer studio"
> # You get a single result: Red Hat JBoss Developer Studio 9.0.0 GA
> # Install it
> # Restart
> # Observe: the EGit views and preferences are missing
> # Observe: you get messages in the Eclipse error log concerning a dependency version incompatibility
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBDS-3673) JBoss EAP 6.x server fails to stop in JBDS 9 , if a port-offset is used.
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3673?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov reassigned JBDS-3673:
------------------------------------
Assignee: Rob Stryker (was: Max Rydahl Andersen)
> JBoss EAP 6.x server fails to stop in JBDS 9 , if a port-offset is used.
> ------------------------------------------------------------------------
>
> Key: JBDS-3673
> URL: https://issues.jboss.org/browse/JBDS-3673
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: server
> Affects Versions: 9.0.0.GA
> Reporter: Harshada Boob
> Assignee: Rob Stryker
> Attachments: .log, Screenshot-JBoss - JBoss EAP 6.4 - JBoss Developer Studio .png
>
>
> 1. When EAP 6.4.x is started with a port-offset, the EAP server starts succesfully and works all good, but there is an issue while stopping the server from JBDS.
> 2. It fails to stop when clicking for the first time on the 'stop' button in the 'server' tab/window and then the server process is terminated/killed if you again try to stop the server by second time clicking on the 'stop' button in the server tab.
> 3. Attached is the screenshot - which is seen when you try to stop the server for the first time and following exception is seen in the workspace/.metadat/.log file (File attached):
> -------------------------------------------------------------------------------------------------------------------
> org.jboss.ide.eclipse.as.management.core.JBoss7ManangerException: java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to http-remoting://localhost:10000. The connection failed
> at org.jboss.ide.eclipse.as.internal.management.wildfly9.Wildfly9Manager.execute(Wildfly9Manager.java:361)
> at org.jboss.ide.eclipse.as.internal.management.wildfly9.Wildfly9ManagerService.execute(Wildfly9ManagerService.java:171)
> at org.jboss.ide.eclipse.as.management.core.JBoss7ManagerServiceProxy.execute(JBoss7ManagerServiceProxy.java:87)
> at org.jboss.ide.eclipse.as.management.core.service.DelegatingManagerService.execute(DelegatingManagerService.java:132)
> at org.jboss.ide.eclipse.as.management.core.JBoss7ManagerServiceProxy.execute(JBoss7ManagerServiceProxy.java:87)
> at org.jboss.ide.eclipse.as.core.server.internal.v7.AS7DeploymentScannerUtility$1.execute(AS7DeploymentScannerUtility.java:291)
> at org.jboss.ide.eclipse.as.core.server.internal.v7.AS7DeploymentScannerUtility$1.execute(AS7DeploymentScannerUtility.java:1)
> at org.jboss.ide.eclipse.as.management.core.JBoss7ManagerUtil.executeWithService(JBoss7ManagerUtil.java:136)
> at org.jboss.ide.eclipse.as.core.server.internal.v7.AS7DeploymentScannerUtility.executeWithResult(AS7DeploymentScannerUtility.java:289)
> at org.jboss.ide.eclipse.as.core.server.internal.v7.AS7DeploymentScannerUtility.getDeploymentScanners(AS7DeploymentScannerUtility.java:161)
> at org.jboss.ide.eclipse.as.core.server.internal.v7.AS7DeploymentScannerUtility.getDeploymentScannersFromServer(AS7DeploymentScannerUtility.java:249)
> at org.jboss.ide.eclipse.as.core.server.internal.v7.LocalJBoss7DeploymentScannerAdditions.loadScannersFromServer(LocalJBoss7DeploymentScannerAdditions.java:173)
> at org.jboss.ide.eclipse.as.core.server.internal.v7.LocalJBoss7DeploymentScannerAdditions.loadScannersFromServerSafely(LocalJBoss7DeploymentScannerAdditions.java:135)
> at org.jboss.ide.eclipse.as.core.server.internal.v7.LocalJBoss7DeploymentScannerAdditions.ensureScannersRemoved(LocalJBoss7DeploymentScannerAdditions.java:150)
> at org.jboss.ide.eclipse.as.core.server.internal.AbstractDeploymentScannerAdditions.removeAddedDeploymentScanners(AbstractDeploymentScannerAdditions.java:83)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.LocalLegacyShutdownController.removeScanners(LocalLegacyShutdownController.java:75)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.LocalLegacyShutdownController.stop(LocalLegacyShutdownController.java:58)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.LocalLegacyShutdownController.stop(LocalLegacyShutdownController.java:53)
> at org.jboss.ide.eclipse.as.wtp.core.server.behavior.ControllableServerBehavior.stop(ControllableServerBehavior.java:252)
> at org.eclipse.wst.server.core.internal.Server.stopImpl2(Server.java:3688)
> at org.eclipse.wst.server.core.internal.Server.stopImpl(Server.java:3645)
> at org.eclipse.wst.server.core.internal.Server$StopJob.run(Server.java:403)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to http-remoting://localhost:10000. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
> at org.jboss.ide.eclipse.as.internal.management.wildfly9.Wildfly9Manager.execute(Wildfly9Manager.java:350)
> ... 22 more
> Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to http-remoting://localhost:10000. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:122)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:212)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> ... 24 more
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:416)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:400)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:83)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:114)
> ... 34 more
> ------------------------------------------------------------------------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21791) Forge addon - Changing the current file may cause a "file has changed in file vs memory" issue in Eclipse
by Claus Ibsen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21791?page=com.atlassian.jira.plugi... ]
Claus Ibsen commented on JBIDE-21791:
-------------------------------------
Maybe the forge command can have some details what it requires.
So in my commands its only the current file in the editor that matters. Any other open files that is unsaved I do not touch.
So maybe the command can have a way of saying that its editing the current file, and therefore forge should ensure the file is saved first.
> Forge addon - Changing the current file may cause a "file has changed in file vs memory" issue in Eclipse
> ---------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-21791
> URL: https://issues.jboss.org/browse/JBIDE-21791
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: forge
> Affects Versions: 4.3.1.Beta2
> Reporter: Claus Ibsen
> Assignee: George Gastaldi
> Fix For: 4.3.1.CR1
>
> Attachments: eclipse-add.png
>
>
> Similar problem as FORGE-2605 but this time its in Eclipse.
> See the attached screenshot, where I have edited the file camel-context.xml, and then run my forge command, which would insert a Camel endpoint at the cursor position. But eclipse has detected a file conflict as in that dialog.
> I wonder if the fix should be like in IDEA to save the file before the command is run.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21814) Remove --provision flag from CDK Server launch config
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21814?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-21814.
---------------------------------
This is done. Verified in latest JBDS 9.x nightly build.
One downside though is that now you can't check the console for info on openshift on consequent launches of cdk - only on provision you will see the info including url of openshift console and credentials.
> Remove --provision flag from CDK Server launch config
> -----------------------------------------------------
>
> Key: JBIDE-21814
> URL: https://issues.jboss.org/browse/JBIDE-21814
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: cdk
> Affects Versions: 4.3.1.CR1
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Fix For: 4.3.1.CR1
>
>
> When using the latest CDK, calling vagrant up with the --provision flag is unnecessary, as the openshift service now starts automatically, and harmful, as it causes the IP address of the image to change, which makes the vagrant process exit with an error.
> --provision should be removed from the default launch configuration
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21830) Server Adapter wizard: route selected by default is wrong
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21830?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21830:
-------------------------------------
Steps to Reproduce:
# ASSERT: make sure that you have several apps in the same project (and then of course you'll have several routes)
# EXEC: launch server adapter wizard (either via "Servers" view > New > OpenShift > OpenShift 3 or via+underlined text+ context menu "Server Adapter" to a service in explorer)
# EXEC: in server adapter wizard: select 2nd service (or any service other than the 1st)
# EXEC: unfold "Advanced >>" and inspect
Result:
The route that is selected by default is not the right one.
!wrong-default-route.png!
# EXEC: select a different route
# ASSERT: default route should switch over
Result:
It's not changing, it stays the same
# EXEC: hit "Finish" and open the Server Adapter Editor
# ASSERT: the Host that is displayed should be the host that the route is pointing to
Result:
The host is reflecting the 1st route that exists in the project, not even the route that was chosen in the wizard.
was:
# ASSERT: make sure that you have several apps in the same project (and then of course you'll have several routes)
# EXEC: launch server adapter wizard (either via "Servers" view > New > OpenShift > OpenShift 3 or via+underlined text+ context menu "Server Adapter" to a service in explorer)
# EXEC: in server adapter wizard: select 2nd service (or any service other than the 1st)
# EXEC: unfold "Advanced >>" and inspect
Result:
The route that is selected by default is not the right one.
!wrong-default-route.png!
# EXEC: select a different route
# ASSERT: default route should switch over
Result:
It's not changing, it stays the same
> Server Adapter wizard: route selected by default is wrong
> ---------------------------------------------------------
>
> Key: JBIDE-21830
> URL: https://issues.jboss.org/browse/JBIDE-21830
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.3.1.CR1
>
> Attachments: wrong-default-route.png
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month