[JBoss JIRA] (RTGOV-355) UI integration tests fail when run as part of full build
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-355?page=com.atlassian.jira.plugin.... ]
Gary Brown resolved RTGOV-355.
------------------------------
Resolution: Done
> UI integration tests fail when run as part of full build
> --------------------------------------------------------
>
> Key: RTGOV-355
> URL: https://issues.jboss.org/browse/RTGOV-355
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.0.0.Final
>
>
> When the switchyard integration tests are performed as part of a full build of the rtgov-ui, they fail with the following issue:
> {noformat}
> org.overlord.rtgov.ui.tests.services.switchyard.SwitchYardServicesProviderTest Time elapsed: 31011 sec <<< ERROR!
> java.lang.RuntimeException: Could not invoke deployment method: public static org.jboss.shrinkwrap.api.spec.WebArchive org.overlord.rtgov.ui.tests.services.switchyard.SwitchYardServicesProviderTest.createDeployment1()
> at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.invoke(AnnotationDeploymentScenarioGenerator.java:160)
> at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generateDeployment(AnnotationDeploymentScenarioGenerator.java:94)
> at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generate(AnnotationDeploymentScenarioGenerator.java:57)
> at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:100)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.invoke(AnnotationDeploymentScenarioGenerator.java:156)
> ... 56 more
> Caused by: java.lang.RuntimeException: Could not parse pom.xml: /home/gbrown/repositories/overlord/objectiser/rtgov-ui/rtgov-ui-core/pom.xml
> at org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader.createFoundArtifact(ClasspathWorkspaceReader.java:307)
> at org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader.getFoundArtifact(ClasspathWorkspaceReader.java:272)
> at org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader.findArtifact(ClasspathWorkspaceReader.java:194)
> at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:296)
> at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:216)
> at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:193)
> at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:281)
> at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:186)
> at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:412)
> at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:544)
> at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:240)
> at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:333)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenRepositorySystem.resolveDependencies(MavenRepositorySystem.java:114)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:256)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:67)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:49)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:38)
> at org.overlord.rtgov.ui.tests.services.switchyard.SwitchYardServicesProviderTest.createDeployment1(SwitchYardServicesProviderTest.java:65)
> ... 61 more
> Caused by: org.xml.sax.SAXParseException; systemId: file:/home/gbrown/repositories/overlord/objectiser/rtgov-ui/rtgov-ui-core/pom.xml; lineNumber: 56; columnNumber: 3; The markup in the document following the root element must be well-formed.
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:251)
> at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:300)
> at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:205)
> at org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader.loadPom(ClasspathWorkspaceReader.java:313)
> at org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader.createFoundArtifact(ClasspathWorkspaceReader.java:286)
> ... 78 more
> {noformat}
> However when just the tests are performed on their own, they work.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (RTGOV-336) Combine activities recorded across multiple threads
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-336?page=com.atlassian.jira.plugin.... ]
Gary Brown updated RTGOV-336:
-----------------------------
Priority: Minor (was: Major)
> Combine activities recorded across multiple threads
> ---------------------------------------------------
>
> Key: RTGOV-336
> URL: https://issues.jboss.org/browse/RTGOV-336
> Project: RTGov (Run Time Governance)
> Issue Type: Enhancement
> Reporter: Gary Brown
> Assignee: Gary Brown
> Priority: Minor
> Fix For: 2.0.0.Final
>
>
> When capturing activity events via proxies in JBoss Fuse, found that when a service returned an exception, it was handled in a separate thread.
> This resulted in two separate activity units, one for the activities up until the exception, and the other for the activities following the exception.
> This will cause issues with correlation currently, where request/response pairs are expected to be in the same activity unit.
> Two possible solutions:
> (1) work on the correlation of requests/responses across activity units - which will be useful in a wider range of cases.
> (2) enable activities across multiple threads to be combined - i.e. if a subsequent thread is new, allow its relationship with a previous activity event (e.g. the request) to link it to the same activity unit. Not sure of the implications on the API for this.
> This work is related to RTGOV-325.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (RTGOV-440) Add confirmation dialog when deleting situations
by Gary Brown (JIRA)
Gary Brown created RTGOV-440:
--------------------------------
Summary: Add confirmation dialog when deleting situations
Key: RTGOV-440
URL: https://issues.jboss.org/browse/RTGOV-440
Project: RTGov (Run Time Governance)
Issue Type: Feature Request
Components: User Interface
Reporter: Gary Brown
Assignee: Michael Clay
Fix For: 2.0.0.Final
Currently when requesting deletion of a set of situations, it performs the operation immediately.
Was wondering whether we should prompt the user with a standard confirmation dialog of the form "Are you sure you want to delete 'x' situations?" before performing the action?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (RTGOV-416) Investigate solution for deploying ElasticSearch EPN on FSW 6.0
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-416?page=com.atlassian.jira.plugin.... ]
Gary Brown updated RTGOV-416:
-----------------------------
Parent: (was: RTGOV-419)
Issue Type: Task (was: Sub-task)
> Investigate solution for deploying ElasticSearch EPN on FSW 6.0
> ---------------------------------------------------------------
>
> Key: RTGOV-416
> URL: https://issues.jboss.org/browse/RTGOV-416
> Project: RTGov (Run Time Governance)
> Issue Type: Task
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.1.0.Final
>
>
> This task is to investigate options for supporting ElasticSearch capabilities in FSW 6.0.
> RTGOV-342 has provided an event processor for ElasticSearch. However this introduces a new 'service' to represent a KeyValueStore, which ElasticSearch is the first implementation.
> If we want to deploy an ElasticSearch based EPN, this new abstract class (currently located in rtgov-commons) is the only issue.
> There are two current proposed solutions:
> 1) Move the abstract class (within the same package) into the rtgov-elasticsearch package as a temporary measure for the next release.
> The issue with this potential solution is if the jars in FSW6.0 are signed - then it won't be possible to have two jars containing classes in the same package.
> 2) Another temporary solution for the next community release would be to inherit the ElasticSearchKeyValueStore directly from the Service abstract class.
> The implication of this would be the EPN's would need to directly use the ElasticSearchKeyValueStore class, rather than the more generic KeyValueStore class - which means that it won't simply be a configuration change to be able to use an alternative KeyValueStore implementation.
> However, as the ElasticSearchKeyValueStore will be the only implementation at that point, then this would work - we would just need to remember to change the EPN's java code after the release, to again use the generic KeyValueStore abstract class.
> At this point, the second option appears to be best, as it localises the changes to the rtgov-elasticsearch module. The rtgov-commons module can remain untouched.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (RTGOV-416) Investigate solution for deploying ElasticSearch EPN on FSW 6.0
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-416?page=com.atlassian.jira.plugin.... ]
Gary Brown updated RTGOV-416:
-----------------------------
Fix Version/s: 2.1.0.Final
(was: 2.0.0.Final)
Moving to next release, to make any necessary changes to sort out workarounds performed to enable new RTGov UI to be deployed on FSW6.0.
> Investigate solution for deploying ElasticSearch EPN on FSW 6.0
> ---------------------------------------------------------------
>
> Key: RTGOV-416
> URL: https://issues.jboss.org/browse/RTGOV-416
> Project: RTGov (Run Time Governance)
> Issue Type: Sub-task
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.1.0.Final
>
>
> This task is to investigate options for supporting ElasticSearch capabilities in FSW 6.0.
> RTGOV-342 has provided an event processor for ElasticSearch. However this introduces a new 'service' to represent a KeyValueStore, which ElasticSearch is the first implementation.
> If we want to deploy an ElasticSearch based EPN, this new abstract class (currently located in rtgov-commons) is the only issue.
> There are two current proposed solutions:
> 1) Move the abstract class (within the same package) into the rtgov-elasticsearch package as a temporary measure for the next release.
> The issue with this potential solution is if the jars in FSW6.0 are signed - then it won't be possible to have two jars containing classes in the same package.
> 2) Another temporary solution for the next community release would be to inherit the ElasticSearchKeyValueStore directly from the Service abstract class.
> The implication of this would be the EPN's would need to directly use the ElasticSearchKeyValueStore class, rather than the more generic KeyValueStore class - which means that it won't simply be a configuration change to be able to use an alternative KeyValueStore implementation.
> However, as the ElasticSearchKeyValueStore will be the only implementation at that point, then this would work - we would just need to remember to change the EPN's java code after the release, to again use the generic KeyValueStore abstract class.
> At this point, the second option appears to be best, as it localises the changes to the rtgov-elasticsearch module. The rtgov-commons module can remain untouched.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (RTGOV-415) ElasticSearch Activity Store implementation
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-415?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-415:
----------------------------------
Forgot to mention - don't worry about implementing the query method, as this will be deprecated in this next release.
> ElasticSearch Activity Store implementation
> -------------------------------------------
>
> Key: RTGOV-415
> URL: https://issues.jboss.org/browse/RTGOV-415
> Project: RTGov (Run Time Governance)
> Issue Type: Sub-task
> Reporter: Gary Brown
> Assignee: ivan mckinley
> Fix For: 2.0.0.Final
>
>
> Although it is not currently clear whether organisations would rely on ElasticSearch as a database for their activity information, it will be good to be able to offer it as an alternative.
> If configured, then it will store the ActivityUnit, and any subsequent EPN can be used to store the derived information (e.g. situations and response times).
> ElasticSearch has improved its support for backup/restore, so could potentially be used as a primary db for this type of information - although it is not transactional.
> The module should be defined in modules/activity-management/activity-store-es (or elasticsearch - whatever is consistent with RTGOV-342).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (SRAMP-408) Tab completion no longer works in s-ramp CLI
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-408?page=com.atlassian.jira.plugin.... ]
Eric Wittmann commented on SRAMP-408:
-------------------------------------
Note: I tested in Fedora as well with the same results.
> Tab completion no longer works in s-ramp CLI
> --------------------------------------------
>
> Key: SRAMP-408
> URL: https://issues.jboss.org/browse/SRAMP-408
> Project: S-RAMP
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Eric Wittmann
> Assignee: David virgil naranjo
> Fix For: 0.5.0 - API Management
>
>
> The recent change to using AESH has broken tab-completion. For example, I typed the following:
> {code}
> s-ramp> conn
> {code}
> Then I hit "tab" and I got this:
> {code}
> s-ramp> connmp:connect
> {code}
> And the cursor was placed three spaces beyond "connect". After that tab didn't work at all because the command wasn't recognized (obviously).
> If I type s-ramp:connect manually and *then* hit tab, I get this:
> {code}
> s-ramp> s-ramp:connect t:8080/s-ramp-server
> {code}
> Also tab-completion of just the namespace adds an extra space at the end. If I back up one and use tab, I get the list of commands in the namespace but it won't actually complete any of them.
> So I think there is some fundamental problem with the tab completion. I tested on Windows cygwin. I will now go test on Fedora.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months