August 2017 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-24681) ITests: Get rid of AbstractCreateApplicationTest

by Josef Kopriva (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24681?page=com.atlassian.jira.plugi... ] Josef Kopriva updated JBIDE-24681: ---------------------------------- Fix Version/s: 4.5.1.AM2 (was: 4.5.x) > ITests: Get rid of AbstractCreateApplicationTest > ------------------------------------------------ > > Key: JBIDE-24681 > URL: https://issues.jboss.org/browse/JBIDE-24681 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: integration-tests, openshift > Affects Versions: 4.5.0.AM1 > Reporter: Radim Hopp > Assignee: Josef Kopriva > Fix For: 4.5.1.AM2 > > > Use requirements instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24222) CDK3 Server adapter: fails to detect that cdk3 Beta3 was successfully started (on macos/xhyve?)

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24222?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-24222: ------------------------------------- Sprint: devex #130 April 2017, devex #137 September 2017 (was: devex #130 April 2017) > CDK3 Server adapter: fails to detect that cdk3 Beta3 was successfully started (on macos/xhyve?) > ----------------------------------------------------------------------------------------------- > > Key: JBIDE-24222 > URL: https://issues.jboss.org/browse/JBIDE-24222 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: cdk > Affects Versions: 4.4.4.AM2 > Environment: macos > xhyve supervisor > cdk3 beta3 > Reporter: Andre Dietisheim > Assignee: Rob Stryker > Priority: Critical > Labels: help_wanted > Fix For: 4.5.1.AM2 > > Attachments: Screenshot 2017-04-18 16.37.44.png, image-2017-04-04-15-48-59-677.png, server-adapter-error.tiff > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-1163) Fuse - Adapt Server category change in tests

by Tomáš Sedmík (JIRA)

[ https://issues.jboss.org/browse/JBTIS-1163?page=com.atlassian.jira.plugin... ] Tomáš Sedmík closed JBTIS-1163. ------------------------------- Resolution: Done PR was pushed to master > Fuse - Adapt Server category change in tests > -------------------------------------------- > > Key: JBTIS-1163 > URL: https://issues.jboss.org/browse/JBTIS-1163 > Project: JBoss Tools Integration Stack > Issue Type: Task > Components: Fuse IDE, QE > Reporter: Tomáš Sedmík > Assignee: Tomáš Sedmík > Priority: Blocker > Fix For: 11.1.0.GA > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24949) Add support for CDI 2.0

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24949?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-24949: ------------------------------- Fix Version/s: 4.5.x (was: 4.5.0.AM2) > Add support for CDI 2.0 > ----------------------- > > Key: JBIDE-24949 > URL: https://issues.jboss.org/browse/JBIDE-24949 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: cdi > Affects Versions: 4.5.0.AM2 > Reporter: Rastislav Wagner > Assignee: Rastislav Wagner > Fix For: 4.5.x > > > CDI 2.0 was released. See http://www.cdi-spec.org/news/2017/05/15/CDI_2_is_released/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24868) Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session

by Roland Huß (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24868?page=com.atlassian.jira.plugi... ] Roland Huß edited comment on JBIDE-24868 at 8/30/17 5:01 AM: ------------------------------------------------------------- Some remarks: 1) actually I haven't experienced that kind of timeout much (so when debugging with IntelliJ the connection seemed to stay open, maybe IntelliJ is sending some kind of ping, intentional or unintentional). 2) the router timeout is imo the biggest pita. The solution via port-forwarding is often not possible: * A Single Page App's UI doesn't use relative URL to access the backend for requests, so can't be changed to use the forwarded port * The application is composed via MicroServices which are aggregated on the route level (i.e. the router spans and defines the REST URL namespace), so for an application to work it might be mandatory to go over the route (e.g. our Syndesis app is example of this kind of application) 3) On a second thought, I don't think anymore that this is critical. The recommendation to choose to suspend only on the thread should cover 99% of all use cases, so changing the deployment config on the fly (and causing a redeployment for this) is too much effort for too less gain imo. Maybe we could get at least an option to Minishift which can influence the router's global timeout value? For many developers this would be already a big help. was (Author: rhuss): Some remarks: 1) actually I haven't experienced that kind of timeout much (so when debugging with IntelliJ the connection seemed to stay open, maybe IntelliJ is sending some kind of ping, intentional or unintentional). 2) the router timeout is imo the biggest pita. The solution via port-forwarding is often not possible: * A Single Page App's UI doesn't use relative URL to access the backend for requests, so can't be changed to use the forwarded port * The application is composed via MicroServices which are aggregated on the route level (i.e. the routed spans and defines the REST URL namespace), so for an application to work it might be mandatory to go over the route (e.g. our Syndesis app is example of this kind of application) 3) On a second thought, I don't think anymore that this is critical. The recommendation to choose to suspend only on the thread should cover 99% of all use cases, so changing the deployment config on the fly (and causing a redeployment for this) is too much effort for too less gain imo. Maybe we could get at least an option to Minishift which can influence the router's global timeout value? For many developers this would be already a big help. > Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session > ---------------------------------------------------------------------------------------------------------- > > Key: JBIDE-24868 > URL: https://issues.jboss.org/browse/JBIDE-24868 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.5.0.Final > Reporter: Aurélien Pupier > Assignee: Andre Dietisheim > Labels: openshift_v3, server_adapter > Fix For: 4.5.x > > > it will avoid to have "debug connections always killed after 30s staying in a breakpoint" > see https://twitter.com/ro14nd/status/895886024387067904 for source of suggestion > k8 documentations on the matter are here: https://kubernetes.io/docs/tasks/configure-pod-container/configure-livene... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24868) Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session

by Roland Huß (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24868?page=com.atlassian.jira.plugi... ] Roland Huß commented on JBIDE-24868: ------------------------------------ Some remarks: 1) actually I haven't experienced that kind of timeout much (so when debugging with IntelliJ the connection seemed to stay open, maybe IntelliJ is sending some kind of ping, intentional or unintentional). 2) the router timeout is imo the biggest pita. The solution via port-forwarding is often not possible: * A Single Page App's UI doesn't use relative URL to access the backend for requests, so can't be changed to use the forwarded port * The application is composed via MicroServices which are aggregated on the route level (i.e. the routed spans and defines the REST URL namespace), so for an application to work it might be mandatory to go over the route (e.g. our Syndesis app is example of this kind of application) 3) On a second thought, I don't think anymore that this is critical. The recommendation to choose to suspend only on the thread should cover 99% of all use cases, so changing the deployment config on the fly (and causing a redeployment for this) is too much effort for too less gain imo. Maybe we could get at least an option to Minishift which can influence the router's global timeout value? For many developers this would be already a big help. > Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session > ---------------------------------------------------------------------------------------------------------- > > Key: JBIDE-24868 > URL: https://issues.jboss.org/browse/JBIDE-24868 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.5.0.Final > Reporter: Aurélien Pupier > Assignee: Andre Dietisheim > Labels: openshift_v3, server_adapter > Fix For: 4.5.x > > > it will avoid to have "debug connections always killed after 30s staying in a breakpoint" > see https://twitter.com/ro14nd/status/895886024387067904 for source of suggestion > k8 documentations on the matter are here: https://kubernetes.io/docs/tasks/configure-pod-container/configure-livene... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24868) Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session

by Roland Huß (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24868?page=com.atlassian.jira.plugi... ] Roland Huß edited comment on JBIDE-24868 at 8/30/17 5:00 AM: ------------------------------------------------------------- Some remarks: 1) actually I haven't experienced that kind of timeout much (so when debugging with IntelliJ the connection seemed to stay open, maybe IntelliJ is sending some kind of ping, intentional or unintentional). 2) the router timeout is imo the biggest pita. The solution via port-forwarding is often not possible: * A Single Page App's UI doesn't use relative URL to access the backend for requests, so can't be changed to use the forwarded port * The application is composed via MicroServices which are aggregated on the route level (i.e. the routed spans and defines the REST URL namespace), so for an application to work it might be mandatory to go over the route (e.g. our Syndesis app is example of this kind of application) 3) On a second thought, I don't think anymore that this is critical. The recommendation to choose to suspend only on the thread should cover 99% of all use cases, so changing the deployment config on the fly (and causing a redeployment for this) is too much effort for too less gain imo. Maybe we could get at least an option to Minishift which can influence the router's global timeout value? For many developers this would be already a big help. was (Author: rhuss): Some remarks: 1) actually I haven't experienced that kind of timeout much (so when debugging with IntelliJ the connection seemed to stay open, maybe IntelliJ is sending some kind of ping, intentional or unintentional). 2) the router timeout is imo the biggest pita. The solution via port-forwarding is often not possible: * A Single Page App's UI doesn't use relative URL to access the backend for requests, so can't be changed to use the forwarded port * The application is composed via MicroServices which are aggregated on the route level (i.e. the routed spans and defines the REST URL namespace), so for an application to work it might be mandatory to go over the route (e.g. our Syndesis app is example of this kind of application) 3) On a second thought, I don't think anymore that this is critical. The recommendation to choose to suspend only on the thread should cover 99% of all use cases, so changing the deployment config on the fly (and causing a redeployment for this) is too much effort for too less gain imo. Maybe we could get at least an option to Minishift which can influence the router's global timeout value? For many developers this would be already a big help. > Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session > ---------------------------------------------------------------------------------------------------------- > > Key: JBIDE-24868 > URL: https://issues.jboss.org/browse/JBIDE-24868 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.5.0.Final > Reporter: Aurélien Pupier > Assignee: Andre Dietisheim > Labels: openshift_v3, server_adapter > Fix For: 4.5.x > > > it will avoid to have "debug connections always killed after 30s staying in a breakpoint" > see https://twitter.com/ro14nd/status/895886024387067904 for source of suggestion > k8 documentations on the matter are here: https://kubernetes.io/docs/tasks/configure-pod-container/configure-livene... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24949) Add support for CDI 2.0

by Rastislav Wagner (JIRA)

Rastislav Wagner created JBIDE-24949: ---------------------------------------- Summary: Add support for CDI 2.0 Key: JBIDE-24949 URL: https://issues.jboss.org/browse/JBIDE-24949 Project: Tools (JBoss Tools) Issue Type: Feature Request Components: cdi Affects Versions: 4.5.0.AM2 Reporter: Rastislav Wagner Assignee: Rastislav Wagner Fix For: 4.5.0.AM2 CDI 2.0 was released. See http://www.cdi-spec.org/news/2017/05/15/CDI_2_is_released/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24868) Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24868?page=com.atlassian.jira.plugi... ] Jeff MAURY commented on JBIDE-24868: ------------------------------------ [~adietish] So far we have three problems: # the timeout for the Java debug connection (and we use the port forwarding feature for that) # the timeout from the router (because the web browser is using the route) # the pod get rescheduled because of the livenessprobe if Java debug is configured as suspendVM on breakpoint (seems default on Intellij) 1) not sure we can fix it 2) can be solved by using the forwarded port for the pod instead of the route but we will still get the same problem in the forwarded port but I think the timeout on the forwarded port is probably larger that the one on the router so we will have the same status as 1) 3) can be solved by updating the deployment config > Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session > ---------------------------------------------------------------------------------------------------------- > > Key: JBIDE-24868 > URL: https://issues.jboss.org/browse/JBIDE-24868 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.5.0.Final > Reporter: Aurélien Pupier > Assignee: Andre Dietisheim > Labels: openshift_v3, server_adapter > Fix For: 4.5.x > > > it will avoid to have "debug connections always killed after 30s staying in a breakpoint" > see https://twitter.com/ro14nd/status/895886024387067904 for source of suggestion > k8 documentations on the matter are here: https://kubernetes.io/docs/tasks/configure-pod-container/configure-livene... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24873) Add management itests to eap jbds compatibility jenkins job

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24873?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-24873: --------------------------------------- Current status: The tests are added and configured properly to run (finally), but now there are some failures, which Rob will take a look at. Meanwhile, Radim changed the job so that the new results are fetched, so the build is now yellow. > Add management itests to eap jbds compatibility jenkins job > ----------------------------------------------------------- > > Key: JBIDE-24873 > URL: https://issues.jboss.org/browse/JBIDE-24873 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Affects Versions: 4.5.0.Final > Reporter: Martin Malina > Assignee: Rob Stryker > Fix For: 4.5.1.AM2 > > > The EAP team would like us to add this test > org.jboss.tools.as.management.itests > to their compatibility job: > https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view/EAP... > details here: EAP7-194 > The test to be added is run here: > https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... > Cc: [~rob.stryker] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 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 August 2017