[JBoss JIRA] (JBIDE-19506) Connection wizard, Connection: should have unit tests
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19506?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19506:
-------------------------------------
Sprint: devex #123 November 2016 (was: devex #122 October 2016)
> Connection wizard, Connection: should have unit tests
> ------------------------------------------------------
>
> Key: JBIDE-19506
> URL: https://issues.jboss.org/browse/JBIDE-19506
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift_v3, tests
> Fix For: 4.4.2.Final
>
> Original Estimate: 2 days
> Time Spent: 3 days
> Remaining Estimate: 3 days
>
> In the new implementation of the connection wizard, that allows v2 and v3 connections (JBIDE-19096) we have rather complex behaviour that we should assert via unit tests.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-19506) Connection wizard, Connection: should have unit tests
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19506?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19506:
-------------------------------------
Fix Version/s: 4.4.2.Final
(was: 4.4.2.AM3)
> Connection wizard, Connection: should have unit tests
> ------------------------------------------------------
>
> Key: JBIDE-19506
> URL: https://issues.jboss.org/browse/JBIDE-19506
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift_v3, tests
> Fix For: 4.4.2.Final
>
> Original Estimate: 2 days
> Time Spent: 3 days
> Remaining Estimate: 3 days
>
> In the new implementation of the connection wizard, that allows v2 and v3 connections (JBIDE-19096) we have rather complex behaviour that we should assert via unit tests.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23019) Integration tests: have them running automatically, continuously
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23019?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-23019:
-------------------------------------
Fix Version/s: 4.4.2.Final
(was: 4.4.2.AM3)
> Integration tests: have them running automatically, continuously
> ----------------------------------------------------------------
>
> Key: JBIDE-23019
> URL: https://issues.jboss.org/browse/JBIDE-23019
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: integration_tests
> Fix For: 4.4.2.Final
>
>
> The integration tests suite is very lenghty to run and should thus be run in a continuous manner on our CI.
> There are several pain-points currently:
> - there's no dedicated OS instance to run them against
> - tests are not stable
> - etc.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23019) Integration tests: have them running automatically, continuously
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23019?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-23019:
-------------------------------------
Sprint: devex #123 November 2016 (was: devex #122 October 2016)
> Integration tests: have them running automatically, continuously
> ----------------------------------------------------------------
>
> Key: JBIDE-23019
> URL: https://issues.jboss.org/browse/JBIDE-23019
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: integration_tests
> Fix For: 4.4.2.Final
>
>
> The integration tests suite is very lenghty to run and should thus be run in a continuous manner on our CI.
> There are several pain-points currently:
> - there's no dedicated OS instance to run them against
> - tests are not stable
> - etc.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBDS-4149) JavaEE Web Project > Run As > Maven not working - constraint violation: javax.servlet-api 3.1.0 and javax.servlet 3.1.0.v201410161800
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4149?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-4149:
----------------------------------
Still seeing the same error as of 10.2 0.20161102.2125.el7 [^rh-eclipse46-devstudio10.2.log.20161102-1855.txt]
> JavaEE Web Project > Run As > Maven not working - constraint violation: javax.servlet-api 3.1.0 and javax.servlet 3.1.0.v201410161800
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-4149
> URL: https://issues.jboss.org/browse/JBDS-4149
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: maven, rpm
> Affects Versions: 10.2.0.AM3
> Environment: RHEL7 64bit
> Reporter: Lukáš Valach
> Assignee: Nick Boldt
> Priority: Critical
> Fix For: 10.2.0.AM3
>
> Attachments: ClassNotFoundEx_20161102_095940.png, eclipse.log, eclipse_10.2-0.20161101.1258.log, javax.servlet.310rpm_vs_orbit.png, rh-eclipse46-devstudio-snapshots-10_2.repo, rh-eclipse46-devstudio10.2.log.20161102-1855.txt, rh-eclipse46.repo
>
>
> I am not able to use embedded Maven. When I try to run Maven clean (or whatever else) I get following error message:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/Logger
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
> at java.lang.Class.getMethod0(Class.java:3018)
> at java.lang.Class.getMethod(Class.java:1784)
> at org.codehaus.plexus.classworlds.launcher.Launcher.getEnhancedMainMethod(Launcher.java:172)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:268)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.Logger
> at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 10 more
> {code}
> Standalone maven installation works fine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBDS-4149) JavaEE Web Project > Run As > Maven not working - constraint violation: javax.servlet-api 3.1.0 and javax.servlet 3.1.0.v201410161800
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4149?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-4149:
-----------------------------
Attachment: rh-eclipse46-devstudio10.2.log.20161102-1855.txt
> JavaEE Web Project > Run As > Maven not working - constraint violation: javax.servlet-api 3.1.0 and javax.servlet 3.1.0.v201410161800
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-4149
> URL: https://issues.jboss.org/browse/JBDS-4149
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: maven, rpm
> Affects Versions: 10.2.0.AM3
> Environment: RHEL7 64bit
> Reporter: Lukáš Valach
> Assignee: Nick Boldt
> Priority: Critical
> Fix For: 10.2.0.AM3
>
> Attachments: ClassNotFoundEx_20161102_095940.png, eclipse.log, eclipse_10.2-0.20161101.1258.log, javax.servlet.310rpm_vs_orbit.png, rh-eclipse46-devstudio-snapshots-10_2.repo, rh-eclipse46-devstudio10.2.log.20161102-1855.txt, rh-eclipse46.repo
>
>
> I am not able to use embedded Maven. When I try to run Maven clean (or whatever else) I get following error message:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/Logger
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
> at java.lang.Class.getMethod0(Class.java:3018)
> at java.lang.Class.getMethod(Class.java:1784)
> at org.codehaus.plexus.classworlds.launcher.Launcher.getEnhancedMainMethod(Launcher.java:172)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:268)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.Logger
> at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 10 more
> {code}
> Standalone maven installation works fine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBDS-4146) Updating the index from remote ‘https://aer.ctrlflow.com/downloads/redhat/problems.zip’ failed with exception: org.apache.lucene.index.IndexFormatTooOldException
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4146?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-4146:
-----------------------------
Attachment: rh-eclipse46-devstudio10.2.log.20161102-1855.txt
> Updating the index from remote ‘https://aer.ctrlflow.com/downloads/redhat/problems.zip’ failed with exception: org.apache.lucene.index.IndexFormatTooOldException
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-4146
> URL: https://issues.jboss.org/browse/JBDS-4146
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, rpm, webservices
> Affects Versions: 10.2.0.AM2
> Reporter: Nick Boldt
> Assignee: Jeff MAURY
> Priority: Blocker
> Fix For: 10.2.0.AM3
>
> Attachments: rh-eclipse46-devstudio10.2.log.20161102-1855.txt
>
>
> As of the latest rpm build [1] I'm only getting this one error now:
> {code}!ENTRY org.eclipse.epp.logging.aeri.ide 2 10 2016-10-28 14:32:25.075
> !MESSAGE Updating the index from remote ‘https://aer.ctrlflow.com/downloads/redhat/problems.zip’ failed with exception: org.apache.lucene.index.IndexFormatTooOldException: Format version is not supported (resource BufferedChecksumIndexInput(MMapIndexInput(path="/tmp/1477679545041-0/segments_1"))): -11 (needs to be between 1071082519 and 1071082519). This version of Lucene only supports indexes created with release 4.0 and later. ; version: 2.0.3.201610111629
> !STACK 0
> org.eclipse.epp.logging.aeri.core.util.Logs$LogTraceException
> at org.eclipse.epp.logging.aeri.core.util.Logs$LogTraceException.newTrace(Logs.java:387)
> at org.eclipse.epp.logging.aeri.core.util.Logs.log(Logs.java:134)
> at org.eclipse.epp.internal.logging.aeri.ide.server.mars.ServerProblemsHistory$UpdateIndexJob.run(ServerProblemsHistory.java:322)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBDS-4146) Updating the index from remote ‘https://aer.ctrlflow.com/downloads/redhat/problems.zip’ failed with exception: org.apache.lucene.index.IndexFormatTooOldException
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4146?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-4146:
----------------------------------
Same error logged (twice) as of 10.2 0.20161102.2125.el7 rpm. [^rh-eclipse46-devstudio10.2.log.20161102-1855.txt]
> Updating the index from remote ‘https://aer.ctrlflow.com/downloads/redhat/problems.zip’ failed with exception: org.apache.lucene.index.IndexFormatTooOldException
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-4146
> URL: https://issues.jboss.org/browse/JBDS-4146
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, rpm, webservices
> Affects Versions: 10.2.0.AM2
> Reporter: Nick Boldt
> Assignee: Jeff MAURY
> Priority: Blocker
> Fix For: 10.2.0.AM3
>
> Attachments: rh-eclipse46-devstudio10.2.log.20161102-1855.txt
>
>
> As of the latest rpm build [1] I'm only getting this one error now:
> {code}!ENTRY org.eclipse.epp.logging.aeri.ide 2 10 2016-10-28 14:32:25.075
> !MESSAGE Updating the index from remote ‘https://aer.ctrlflow.com/downloads/redhat/problems.zip’ failed with exception: org.apache.lucene.index.IndexFormatTooOldException: Format version is not supported (resource BufferedChecksumIndexInput(MMapIndexInput(path="/tmp/1477679545041-0/segments_1"))): -11 (needs to be between 1071082519 and 1071082519). This version of Lucene only supports indexes created with release 4.0 and later. ; version: 2.0.3.201610111629
> !STACK 0
> org.eclipse.epp.logging.aeri.core.util.Logs$LogTraceException
> at org.eclipse.epp.logging.aeri.core.util.Logs$LogTraceException.newTrace(Logs.java:387)
> at org.eclipse.epp.logging.aeri.core.util.Logs.log(Logs.java:134)
> at org.eclipse.epp.internal.logging.aeri.ide.server.mars.ServerProblemsHistory$UpdateIndexJob.run(ServerProblemsHistory.java:322)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23358) OpenShift Explorer: Pod status is not reflecting reality
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23358?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-23358:
-------------------------------------
Steps to Reproduce:
ASSERT: Have an OpenShift connection with a project and a docker connection with a local image.
EXEC: in Docker Explorer: Select the docker image and select its context menu item Deploy to OpenShift.
EXEC: Proceed through Deploy Image to OpenShift wizard but do not push image to OpenShift registry.
RESULT: Deployment fails and status of pods is Crash loop back off, but status of pod in OpenShift Explorer is still Running.
EXPECTED RESULT: Status of failed pod in OpenShift explorer reflects reality.
was:
ASSERT: Have an OpenShift connection with a project and a docker connection with a local image.
EXEC: Select the docker image and select its context menu item Deploy to OpenShift.
EXEC: Proceed through Deploy Image to OpenShift wizard but do not push image to OpenShift registry.
RESULT: Deployment fails and status of pods is Crash loop back off, but status of pod in OpenShift Explorer is still Running.
EXPECTED RESULT: Status of failed pod in OpenShift explorer reflects reality.
> OpenShift Explorer: Pod status is not reflecting reality
> --------------------------------------------------------
>
> Key: JBIDE-23358
> URL: https://issues.jboss.org/browse/JBIDE-23358
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.2.AM2
> Reporter: Marián Labuda
> Assignee: Dmitrii Bocharov
> Labels: openshift_v3
> Fix For: 4.4.x
>
> Attachments: pod_status.png
>
>
> When I have a pod with failed status, it is not correctly displayed in tooling. Pod under a service has status Running (as styled next next to tree item as well as property value in property view). Current status is failed, precisely "Crash loop back off" (happens often when there are problems with fetching an image...). The correct status is shown in Web-UI as well as from oc binary "oc get pods". Refresh of a project or service does not help.
> !pod_status.png!
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23030) Scaling a service changes the wrong deployment
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23030?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-23030:
-------------------------------------
Comment: was deleted
(was: I have the erroneous scaling info coming up even with my patch in place. Trying to fix this and update my PR.)
> Scaling a service changes the wrong deployment
> ----------------------------------------------
>
> Key: JBIDE-23030
> URL: https://issues.jboss.org/browse/JBIDE-23030
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Priority: Critical
> Fix For: 4.4.2.AM3
>
> Attachments: rc-1-replicas-0.png, rc2-replicas-1.png, replicas-0.png, scale-to-shows-old-rc.ogv
>
>
> In openshift explorer, when scaling a service that has 2 deployments, it deploys pod from the oldest deployment instead of the latest. Eventually, these pods are killed by openshift.
> The workaround is to open the properties view and issue a scale command on a deployment directly.
> However, because scaling is such a front-and-center feature from the explorer, I believe it's critical we fix it ASAP
> (copied from JBIDE-23412)
> The following steps can be seen in the following screencast:
> [^scale-to-shows-old-rc.ogv]
> # ASSERT: have an app running (ex. nodejs-example)
> # ASSERT: In OpenShift Explorer: make sure it has at least 1 pod: pick "Scale To" in the context menu of the service. Dialog shows that there's at least 1 pod currently
> # ASSERT: in OpenShift Explorer: there 1 pod shown as child to the service.
> # ASSERT: in Properties view, pick "Deployments" tab and see that there's at least 1 deployment (aka replication controller)
> # EXEC: in OpenShift explorer: select Service pick "Deploy Latest"
> # ASSERT: in Properties view: "Deployments" now shows 2 Deployments
> # ASSERT: in OpenShift Explorer you now see 2 children/pods
> # EXEC: in OpenShift Explorer: pick "Scale To..." in the context menu of the service
> Result:
> The current number of pods is shown as 0.
> !replicas-0.png!
> But it's very sure that this is not true. Behind the scenes a new replication controller was created which deployed a new pod:
> !rc2-replicas-1.png!
> The old replication controller was turned to have 0 pods. The "Scale To" dialog shows the number of replcas for the old replication controller.
> !rc-1-replicas-0.png!
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months