November 2016 - jbosstools-issues

[JBoss JIRA] (JBIDE-22376) Enable JMX when entering Debug mode

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22376?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-22376: -------------------------------- Fix Version/s: 4.4.3.AM1 4.5.0.AM1 (was: 4.4.x) > Enable JMX when entering Debug mode > ----------------------------------- > > Key: JBIDE-22376 > URL: https://issues.jboss.org/browse/JBIDE-22376 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.1.1.Beta1 > Reporter: Thomas Mäder > Assignee: Rob Stryker > Fix For: 4.4.3.AM1, 4.5.0.AM1 > > > We need to update the deployment configuration when entering debug mode. It is not entirely clear how to determine that an Openshift Pod has indeed a wildfly/EAP in it and can be reached with remoting-jmx -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16539) move pollthread mechanism into subsystem

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16539?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-16539. --------------------------------- Fix Version/s: 4.4.2.AM3 (was: LATER) Assignee: Rob Stryker Resolution: Rejected Since the public API is already very suitable, and the polling mechanism can be seen as an internal detail of the startup / shutdown controllers, I have no plans on rocking the boat for polling. It's more likely to cause errors than to improve anything. > move pollthread mechanism into subsystem > ----------------------------------------- > > Key: JBIDE-16539 > URL: https://issues.jboss.org/browse/JBIDE-16539 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: server > Reporter: Max Rydahl Andersen > Assignee: Rob Stryker > Fix For: 4.4.2.AM3 > > > JBIDE-16533 revealed poll threads are handled via global static singleton - a less than perfect fit for the subsystem mechanism. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22201) Error contacting OpenShift after CDK is started

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22201?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-22201. --------------------------------- Resolution: Done https://github.com/projectatomic/adb-utils/issues/194 Seems this was recognized and fixed. Will be in CDK 2.3 release. I also recently added a 2-3 second delay, which seemed to fix most of the problems, but this should definitely be fixed now. > Error contacting OpenShift after CDK is started > ----------------------------------------------- > > Key: JBIDE-22201 > URL: https://issues.jboss.org/browse/JBIDE-22201 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: cdk, openshift > Affects Versions: 4.3.1.Final > Reporter: Martin Malina > Assignee: Rob Stryker > Fix For: 4.4.2.AM3 > > > Today Marian and I started seeing this issue: When we start CDK, it will start and everything seems to work, but an error pops up: > {code} > Error contacting OpenShift > org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller$OpenShiftNotReadyPollingException: The CDK VM is up and running, but OpenShift is unreachable at url https://10.1.2.2:8443/healthz/ready > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.checkOpenShiftHealth(VagrantPoller.java:209) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.checkOpenShiftHealth(VagrantPoller.java:186) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePing(VagrantPoller.java:170) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePingSafe(VagrantPoller.java:150) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.getCurrentStateSynchronous(VagrantPoller.java:129) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.handleProcessTerminated(CDKLaunchController.java:248) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.access$2(CDKLaunchController.java:240) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController$2.run(CDKLaunchController.java:233) > {code} > When you actually copy&paste that url into a browser, you will get "ok". > This happens to me on OS X with CDK 2.0 CR3 (the latest build). Marian is on Linux (Fedora 22). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22201) Error contacting OpenShift after CDK is started

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22201?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-22201: -------------------------------- Fix Version/s: 4.4.2.AM3 (was: 4.4.x) > Error contacting OpenShift after CDK is started > ----------------------------------------------- > > Key: JBIDE-22201 > URL: https://issues.jboss.org/browse/JBIDE-22201 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: cdk, openshift > Affects Versions: 4.3.1.Final > Reporter: Martin Malina > Assignee: Rob Stryker > Fix For: 4.4.2.AM3 > > > Today Marian and I started seeing this issue: When we start CDK, it will start and everything seems to work, but an error pops up: > {code} > Error contacting OpenShift > org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller$OpenShiftNotReadyPollingException: The CDK VM is up and running, but OpenShift is unreachable at url https://10.1.2.2:8443/healthz/ready > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.checkOpenShiftHealth(VagrantPoller.java:209) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.checkOpenShiftHealth(VagrantPoller.java:186) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePing(VagrantPoller.java:170) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePingSafe(VagrantPoller.java:150) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.getCurrentStateSynchronous(VagrantPoller.java:129) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.handleProcessTerminated(CDKLaunchController.java:248) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.access$2(CDKLaunchController.java:240) > at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController$2.run(CDKLaunchController.java:233) > {code} > When you actually copy&paste that url into a browser, you will get "ok". > This happens to me on OS X with CDK 2.0 CR3 (the latest build). Marian is on Linux (Fedora 22). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19532) "Edit Server Runtime Environment" Dialog configuration validation is broken

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19532?page=com.atlassian.jira.plugi... ] Rob Stryker closed JBIDE-19532. ------------------------------- Fix Version/s: 4.4.2.AM3 (was: 4.4.x) Resolution: Rejected >From what I can tell, the usecase was invalid. > "Edit Server Runtime Environment" Dialog configuration validation is broken > --------------------------------------------------------------------------- > > Key: JBIDE-19532 > URL: https://issues.jboss.org/browse/JBIDE-19532 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.2.3.CR1 > Reporter: Denis Golovin > Assignee: Denis Golovin > Priority: Minor > Fix For: 4.4.2.AM3 > > Attachments: data-folder-config.png, Edit Server Runtime Environment _102.png, JBIDE-19532.png > > > If I use "Browse" button for "Configuration base directory" and "Configuration file" validation has no complains, but result is broken Server that cannot start. > {code}java.lang.IllegalStateException: basedir /home/eskimo/Java/wildfly-8.0.0.Final/configuration does not exist. > at org.apache.tools.ant.DirectoryScanner.scan(DirectoryScanner.java:879) > at org.jboss.ide.eclipse.as.core.extensions.descriptors.AntFileFilter.getIncludedFiles(AntFileFilter.java:40) > at org.jboss.ide.eclipse.as.core.extensions.descriptors.XPathQuery.refresh(XPathQuery.java:133) > at org.jboss.tools.as.core.server.controllable.subsystems.internal.XPathsPortsController.findPort(XPathsPortsController.java:80) > at org.jboss.tools.as.core.server.controllable.subsystems.internal.XPathsPortsController.getPortOffset(XPathsPortsController.java:128) > at org.jboss.tools.as.core.server.controllable.subsystems.internal.XPathsPortsController.getJBossWebPort(XPathsPortsController.java:110) > at org.jboss.tools.as.core.server.controllable.subsystems.internal.XPathsPortsController.findPort(XPathsPortsController.java:58) > at org.jboss.ide.eclipse.as.core.server.internal.JBossServer.findPort(JBossServer.java:209) > at org.jboss.ide.eclipse.as.core.server.internal.JBossServer.getJBossWebPort(JBossServer.java:195) > at org.jboss.ide.eclipse.as.core.extensions.polling.WebPortPoller.getURL(WebPortPoller.java:84) > at org.jboss.ide.eclipse.as.core.extensions.polling.WebPortPoller.getCurrentStateSynchronous(WebPortPoller.java:155) > at org.jboss.ide.eclipse.as.core.util.PollThreadUtils.isServerStarted(PollThreadUtils.java:227) > at org.jboss.ide.eclipse.as.core.util.PollThreadUtils.isServerStarted(PollThreadUtils.java:213) > at org.jboss.ide.eclipse.as.core.server.internal.launch.StandardLocalJBossStartLaunchDelegate.isServerStarted(StandardLocalJBossStartLaunchDelegate.java:68) > at org.jboss.ide.eclipse.as.wtp.core.server.launch.AbstractStartJavaServerLaunchDelegate.preLaunchCheck(AbstractStartJavaServerLaunchDelegate.java:117) > at org.jboss.tools.as.core.server.controllable.subsystems.internal.LocalJBossLaunchController.preLaunchCheck(LocalJBossLaunchController.java:119) > at org.jboss.ide.eclipse.as.wtp.core.server.launch.ControllableServerLaunchConfiguration.preLaunchCheck(ControllableServerLaunchConfiguration.java:86) > at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:840) > at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739) > at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731) > at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3541) > at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3477) > at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:367) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13481) When runtime is not found, ask user before adding path to list for scanning

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13481?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-13481: -------------------------------- Sprint: devex #123 November 2016 > When runtime is not found, ask user before adding path to list for scanning > --------------------------------------------------------------------------- > > Key: JBIDE-13481 > URL: https://issues.jboss.org/browse/JBIDE-13481 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: runtime-detection > Affects Versions: 4.0.0.Final > Reporter: Michelle Murray > Assignee: Rob Stryker > Fix For: 4.4.2.Final > > > 1. Click Window > Preferences > JBoss Tools > JBoss Tools Runtime Detection > 2. Click Add and select a random directory without a runtime > 3. Next window displays 'No runtime found' (as expected!) > 4. Click Cancel > 5. Despite no runtime being found this path has been added to the list of paths to scan. > I can understand that some users might want to add paths despite runtimes not being found - hence current behavior. But some users might just be searching for a runtime location using trial and error and it can become frustrating to have to then select the path and click Remove. > Could this be improved by adding a step between 4 and 5? So after clicking Cancel a message is displayed to say 'No runtime was found. Are you sure you want to add this path?' with yes/no options, where yes adds the path and no doesn't add it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13481) When runtime is not found, ask user before adding path to list for scanning

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13481?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-13481: -------------------------------- Fix Version/s: 4.4.2.Final (was: 4.1.x) > When runtime is not found, ask user before adding path to list for scanning > --------------------------------------------------------------------------- > > Key: JBIDE-13481 > URL: https://issues.jboss.org/browse/JBIDE-13481 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: runtime-detection > Affects Versions: 4.0.0.Final > Reporter: Michelle Murray > Assignee: Rob Stryker > Fix For: 4.4.2.Final > > > 1. Click Window > Preferences > JBoss Tools > JBoss Tools Runtime Detection > 2. Click Add and select a random directory without a runtime > 3. Next window displays 'No runtime found' (as expected!) > 4. Click Cancel > 5. Despite no runtime being found this path has been added to the list of paths to scan. > I can understand that some users might want to add paths despite runtimes not being found - hence current behavior. But some users might just be searching for a runtime location using trial and error and it can become frustrating to have to then select the path and click Remove. > Could this be improved by adding a step between 4 and 5? So after clicking Cancel a message is displayed to say 'No runtime was found. Are you sure you want to add this path?' with yes/no options, where yes adds the path and no doesn't add it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13481) When runtime is not found, ask user before adding path to list for scanning

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13481?page=com.atlassian.jira.plugi... ] Rob Stryker reassigned JBIDE-13481: ----------------------------------- Assignee: Rob Stryker (was: Snjezana Peco) > When runtime is not found, ask user before adding path to list for scanning > --------------------------------------------------------------------------- > > Key: JBIDE-13481 > URL: https://issues.jboss.org/browse/JBIDE-13481 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: runtime-detection > Affects Versions: 4.0.0.Final > Reporter: Michelle Murray > Assignee: Rob Stryker > Fix For: 4.4.2.Final > > > 1. Click Window > Preferences > JBoss Tools > JBoss Tools Runtime Detection > 2. Click Add and select a random directory without a runtime > 3. Next window displays 'No runtime found' (as expected!) > 4. Click Cancel > 5. Despite no runtime being found this path has been added to the list of paths to scan. > I can understand that some users might want to add paths despite runtimes not being found - hence current behavior. But some users might just be searching for a runtime location using trial and error and it can become frustrating to have to then select the path and click Remove. > Could this be improved by adding a step between 4 and 5? So after clicking Cancel a message is displayed to say 'No runtime was found. Are you sure you want to add this path?' with yes/no options, where yes adds the path and no doesn't add it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21857) Hot class reload doesn't work on OpenShift

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21857?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-21857: -------------------------------- Sprint: devex #123 November 2016 > Hot class reload doesn't work on OpenShift > ------------------------------------------ > > Key: JBIDE-21857 > URL: https://issues.jboss.org/browse/JBIDE-21857 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.Beta2 > Reporter: Fred Bricon > Assignee: Rob Stryker > Fix For: 4.4.x > > Attachments: HCRFailure.zip > > > When enabling debug mode on an EAP server deployed on OpenShift, locally changing a class file will : > - work sometimes when only the content of the method changed, but could fail in some other occasions with the Debugger saying the JDK is out of sync > - will always fail if a method signature changed, the debugger saying JDK is out of sync > Restarting the deployed module (with the .dodeploy flag) doesn't fixes the issue (as opposed to the same tweak ahen running on a local EAP server) > This may be caused by running OpenJDK? Does it support the same level of debugging as Oracle JDK? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22376) Enable JMX when entering Debug mode

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22376?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-22376: -------------------------------- Sprint: devex #123 November 2016 > Enable JMX when entering Debug mode > ----------------------------------- > > Key: JBIDE-22376 > URL: https://issues.jboss.org/browse/JBIDE-22376 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.1.1.Beta1 > Reporter: Thomas Mäder > Assignee: Rob Stryker > Fix For: 4.4.x > > > We need to update the deployment configuration when entering debug mode. It is not entirely clear how to determine that an Openshift Pod has indeed a wildfly/EAP in it and can be reached with remoting-jmx -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues November 2016