[JBoss JIRA] (JBIDE-22598) Support runtime detection for manual CDK install
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22598?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22598:
--------------------------------
Sprint: devex #121 October 2016 (was: devex #120 September 2016)
> Support runtime detection for manual CDK install
> ------------------------------------------------
>
> Key: JBIDE-22598
> URL: https://issues.jboss.org/browse/JBIDE-22598
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdk, runtime-detection
> Affects Versions: 4.4.0.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.x
>
>
> Right now with CDK 2.1 when you have a manual cdk install (i.e. using cdk.zip and then adding the vagrant box yourself), there will be no .cdk marker, so Runtime Detection will not work.
> The only case where Runtime Detection will work is when you use the (as of now Windows-only) suite installer. At that point Runtime Detection will do its thing silently without you noticing.
> The way I see it there are two options:
> a) Create and upstream issue with CDK and ask them to include a basic .cdk in their zip
> b) Make the runtime detection work without .cdk
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 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 #121 October 2016 (was: devex #120 September 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: Rob Stryker
> Fix For: 4.4.2.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, 6 months
[JBoss JIRA] (JBIDE-18912) Custom deploy dir with remote server using filesystem operations does not work
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18912?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-18912:
--------------------------------
Sprint: devex #121 October 2016 (was: devex #120 September 2016)
> Custom deploy dir with remote server using filesystem operations does not work
> ------------------------------------------------------------------------------
>
> Key: JBIDE-18912
> URL: https://issues.jboss.org/browse/JBIDE-18912
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.1.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Labels: help_wanted
> Fix For: 4.4.2.AM1
>
>
> This is a follow up of JBIDE-17180 and JBIDE-13445 which added the option to add a custom deployment directory if your remote server is using filesystem operations (for management api it's not relevant since the deployment happens directly, no directory is used).
> Unfortunately it does not work. It seems I haven't really tried it when reviewing those other JIRAs because there were other obstacles.
> I tried this several times and still could not get it to work.
> Perhaps it might be worth to try and get this in the final 4.2.1.Final build?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-20108) Cannot connect to remote server in JMX Navigator - Authentication fails
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20108?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-20108:
--------------------------------
Sprint: devex #121 October 2016 (was: devex #120 September 2016)
> Cannot connect to remote server in JMX Navigator - Authentication fails
> -----------------------------------------------------------------------
>
> Key: JBIDE-20108
> URL: https://issues.jboss.org/browse/JBIDE-20108
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jmx
> Affects Versions: 4.3.0.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.2.AM1
>
>
> When I try to connect to a remote server via JMX Navigator, it fails on authentication:
> {code}
> !ENTRY org.jboss.ide.eclipse.as.jmx.integration 4 0 2015-06-17 18:07:30.854
> !MESSAGE Error connecting to jmx for server JBoss EAP 6.4 marvin
> !STACK 1
> org.jboss.tools.jmx.core.JMXException: Authentication against the remote JBoss instance has failed. Please verify your management credentials in the server editor.
> at org.jboss.ide.eclipse.as.jmx.integration.JBoss71ServerConnection.createConnection(JBoss71ServerConnection.java:94)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:202)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:162)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.connectToStartedServer(JBossServerConnection.java:332)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.connect(JBossServerConnection.java:76)
> at org.jboss.tools.jmx.core.ConnectJob.run(ConnectJob.java:29)
> at org.jboss.tools.jmx.ui.internal.actions.DoubleClickAction$1.run(DoubleClickAction.java:71)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: javax.security.sasl.SaslException: Authentication failed: the server presented no authentication mechanisms
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:388)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:183)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:198)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
> at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:230)
> at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:151)
> at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:102)
> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at org.jboss.ide.eclipse.as.jmx.integration.JBoss71ServerConnection.createConnection(JBoss71ServerConnection.java:84)
> ... 7 more
> !SUBENTRY 1 org.jboss.ide.eclipse.as.core 4 0 2015-06-17 18:07:30.854
> !MESSAGE Authentication against the remote JBoss instance has failed. Please verify your management credentials in the server editor.
> !STACK 0
> javax.security.sasl.SaslException: Authentication failed: the server presented no authentication mechanisms
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:388)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:183)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:198)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
> at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:230)
> at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:151)
> at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:102)
> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at org.jboss.ide.eclipse.as.jmx.integration.JBoss71ServerConnection.createConnection(JBoss71ServerConnection.java:84)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:202)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:162)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.connectToStartedServer(JBossServerConnection.java:332)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.connect(JBossServerConnection.java:76)
> at org.jboss.tools.jmx.core.ConnectJob.run(ConnectJob.java:29)
> at org.jboss.tools.jmx.ui.internal.actions.DoubleClickAction$1.run(DoubleClickAction.java:71)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
> This is different than JBIDE-19463 where the main problem was the missing runtime and we assumed that otherwise it would work.
> Note: I tried WildFly 8.2, WildFly 9.0.0.CR2, EAP 6.4 and all failed the same way.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-21065) Server host name address should not be defaulted during server adapter creation
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21065?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-21065:
--------------------------------
Sprint: devex #121 October 2016 (was: devex #120 September 2016)
> Server host name address should not be defaulted during server adapter creation
> -------------------------------------------------------------------------------
>
> Key: JBIDE-21065
> URL: https://issues.jboss.org/browse/JBIDE-21065
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server, upstream
> Affects Versions: 4.3.0.Final
> Reporter: Xavier Coulon
> Assignee: Rob Stryker
> Fix For: 4.4.x
>
>
> I've noticed that when I create a server adapter and I give it an IP address as the hostname, the hostname remains the default value, ie, {{localhost}}.
> This is annoying in the case where I want to connect to a VM running on my own host (eg, a VM running Docker). In this particular case, I set the hostname at something like {{192.168.99.100}} but it is reverted as {{localhost}} which gives {{127.0.0.1}} as the primary IP address. As a consequence, the server adapter fails to connect to the server since it uses the wrong IP address.
> Note that the host name can be changed for good in the Server Configuration Editor _after_ its creation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ERT-410) Wrong message when adding duplicate TCP connection [EBZ#500910]
by Jeff Johnston (JIRA)
[ https://issues.jboss.org/browse/ERT-410?page=com.atlassian.jira.plugin.sy... ]
Jeff Johnston resolved ERT-410.
-------------------------------
Fix Version/s: Neon.1 (4.6)
Resolution: Done
> Wrong message when adding duplicate TCP connection [EBZ#500910]
> ---------------------------------------------------------------
>
> Key: ERT-410
> URL: https://issues.jboss.org/browse/ERT-410
> Project: Eclipse Release Train
> Issue Type: Task
> Components: Linux Tools
> Reporter: Friendly Jira Robot
> Assignee: Jeff Johnston
> Priority: Trivial
> Labels: Docker, bzira
> Fix For: Neon.1 (4.6)
>
>
> Created attachment 263985
> Wrong error message TCP connection
> When I am trying to add duplicate TCP connection, an error message is shown: " A connection with the same Unix socket path already exists", but it should be different, for example: "A connection with the same TCP address already exists"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months