[JBoss JIRA] (RTGOV-519) Intercept activity from Vertx app interactions and report as activity events
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-519?page=com.atlassian.jira.plugin.... ]
Gary Brown updated RTGOV-519:
-----------------------------
Assignee: Marc Savy (was: Gary Brown)
> Intercept activity from Vertx app interactions and report as activity events
> ----------------------------------------------------------------------------
>
> Key: RTGOV-519
> URL: https://issues.jboss.org/browse/RTGOV-519
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Gary Brown
> Assignee: Marc Savy
> Fix For: 2.1.0.Final
>
>
> Vertx has a simple core that is not going to be extended to support any form of intercept mechanism.
> The current advice from the vertx team is to create a module that essentially acts as proxy to the real module being used. The problem with this approach is that it does not have any information about the client or service, which are required by rtgov.
> Therefore the suggested approach will be to wrap the event bus api with an implementation that can be configured with information about the verticle in which it is being used. Then it can use that information when a message is being sent or received, to create activity events (e.g. request sent/received, response sent/received).
> The other issue to consider is how to build ActivityUnits out of the various ActivityType events that may be associated with a business transaction instance. In some environments, the thread can be used to track and accumulate multiple activity events to the same unit. However this approach wouldn't work in Vertx.
> One approach to be considered:
> The activity events should be reported to an intermediate module responsible for accumulating events into a unit. If a response is expected, then when recording the request it should record the fact, so that the module building the activity unit can determine when invocation scopes have been completed, and therefore the activity unit submitted. (May be more complex than this, but possibly a starting point). The response handler would need to cache a 'replyTo' id that would enable it to submit response events to the same activity unit. This may be controlled on the client side (i.e. event bus proxy), as it may know when it has finished doing its work.
> Worst case is that each verticle 'instance' would record its activity in a single activity unit - i.e. request received, and sent messages and received responses, before returning its reply.
> Need to investigate whether vertx exposes any form of message ids between verticles - and if not, whether this is something they would consider adding. This would enable correlation of activity across verticles.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (SRAMP-431) Arquillian-based integration tests
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.... ]
Brett Meyer edited comment on SRAMP-431 at 7/6/14 1:51 PM:
-----------------------------------------------------------
Re-wrote the description, after scraping off my Arquillian rust ;)
All, take a look at https://github.com/brmeyer/s-ramp/compare/integration-tests and let me know your thoughts. So far, it downloads Tomcat, unpacks it, and runs the full S-RAMP installer on it. Arquillian runs Tomcat in a managed-mode, then runs a simple client test (passes). EAP setup will be identical, minus the downloading (unpack the distro zip from a known location or support $JBOSS_HOME).
Arquillian does not currently have a Jetty 8 container. Since there is Jetty 7 & 9, I may look into contributing one for 8. However, note that *none* of them support managed-mode -- all require embedded. Do we want to try that for Jetty, or look into writing a managed one?
was (Author: brmeyer):
Re-wrote the description, after scraping off my Arquillian rust ;)
All, take a look at https://github.com/brmeyer/s-ramp/compare/integration-tests and let me know your thoughts. So far, it downloads Tomcat, unpacks it, and runs the full S-RAMP installer on it. Arquillian runs Tomcat in a managed-mode, then runs a simple client test (passes). Jetty's setup will be nearly identical. EAP too, minus the downloading (unpack the distro zip from a known location or support $JBOSS_HOME).
However, Arquillian does not currently have a Jetty 8 container. Since there is Jetty 7 & 9, I may look into contributing one for 8.
> Arquillian-based integration tests
> ----------------------------------
>
> Key: SRAMP-431
> URL: https://issues.jboss.org/browse/SRAMP-431
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> Create a new s-ramp-test module to contain all integration tests. Thoughts:
> - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode."
> - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME
> - Fuse should be run in embedded mode.
> - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s).
> - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works.
> - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests.
> The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (SRAMP-431) Arquillian-based integration tests
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on SRAMP-431:
-----------------------------------
One thought for Fuse:
The test currently runs Arquillian in its "as-client" mode, skipping the @Deployment completely. So that we can simply reuse those tests, we might consider configuring the embedded Fuse container with XML. IIRC, that's possible in Arquillian, rather than having to include another layer in the tests with the Fuse-specific @Deployment.
> Arquillian-based integration tests
> ----------------------------------
>
> Key: SRAMP-431
> URL: https://issues.jboss.org/browse/SRAMP-431
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> Create a new s-ramp-test module to contain all integration tests. Thoughts:
> - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode."
> - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME
> - Fuse should be run in embedded mode.
> - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s).
> - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works.
> - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests.
> The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (SRAMP-431) Arquillian-based integration tests
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on SRAMP-431:
-----------------------------------
Re-wrote the description, after scraping off my Arquillian rust ;)
All, take a look at https://github.com/brmeyer/s-ramp/compare/integration-tests and let me know your thoughts. So far, it downloads Tomcat, unpacks it, and runs the full S-RAMP installer on it. Arquillian runs Tomcat in a managed-mode, then runs a simple client test (passes). Jetty's setup will be nearly identical. EAP too, minus the downloading (unpack the distro zip from a known location or support $JBOSS_HOME).
However, Arquillian does not currently have a Jetty 8 container. Since there is Jetty 7 & 9, I may look into contributing one for 8.
> Arquillian-based integration tests
> ----------------------------------
>
> Key: SRAMP-431
> URL: https://issues.jboss.org/browse/SRAMP-431
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> Create a new s-ramp-test module to contain all integration tests. Thoughts:
> - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode."
> - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME
> - Fuse should be run in embedded mode.
> - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s).
> - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works.
> - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests.
> The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (SRAMP-431) Arquillian-based integration tests
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated SRAMP-431:
------------------------------
Description:
Create a new s-ramp-test module to contain all integration tests. Thoughts:
- 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode."
- The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME
- Fuse should be run in embedded mode.
- No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s).
- Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works.
- Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests.
The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests
was:
Create a new s-ramp-test module to contain all integration tests. Thoughts:
- 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode."
- The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME
- Fuse should be run in embedded mode.
- No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s).
- Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works.
- Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests.
The work-in-progress:
https://github.com/brmeyer/s-ramp/commits/integration-tests
https://github.com/brmeyer/s-ramp/compare/integration-tests
> Arquillian-based integration tests
> ----------------------------------
>
> Key: SRAMP-431
> URL: https://issues.jboss.org/browse/SRAMP-431
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> Create a new s-ramp-test module to contain all integration tests. Thoughts:
> - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode."
> - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME
> - Fuse should be run in embedded mode.
> - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s).
> - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works.
> - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests.
> The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (SRAMP-431) Arquillian-based integration tests
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated SRAMP-431:
------------------------------
Description:
Create a new s-ramp-test module to contain all integration tests. Thoughts:
- 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode."
- The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME
- Fuse should be run in embedded mode.
- No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s).
- Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works.
- Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests.
The work-in-progress:
https://github.com/brmeyer/s-ramp/commits/integration-tests
https://github.com/brmeyer/s-ramp/compare/integration-tests
was:
Create a new s-ramp-test module to contain all integration tests. Thoughts:
- 1 central abstract class (IntegrationTest) that contains all the functional tests and assertions (or if that gets too large, split it up into delegates)
- 1 Arquillian test per supported container, extending the above. Mainly in charge of the @RunWith and @Deployments. Ex: EAPIntegrationTest extends IntegrationTest
- None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it.
- 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode."
- The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME
- Fuse should be run in embedded mode.
The work-in-progress: https://github.com/brmeyer/s-ramp/commits/integration-tests
> Arquillian-based integration tests
> ----------------------------------
>
> Key: SRAMP-431
> URL: https://issues.jboss.org/browse/SRAMP-431
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> Create a new s-ramp-test module to contain all integration tests. Thoughts:
> - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode."
> - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME
> - Fuse should be run in embedded mode.
> - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s).
> - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works.
> - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests.
> The work-in-progress:
> https://github.com/brmeyer/s-ramp/commits/integration-tests
> https://github.com/brmeyer/s-ramp/compare/integration-tests
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (SRAMP-395) S-RAMP allows artifacts to be created with invalid characters in the Artifact Type
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SRAMP-395?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on SRAMP-395:
-----------------------------------------------
Julian Coleman <jcoleman(a)redhat.com> changed the Status of [bug 1114732|https://bugzilla.redhat.com/show_bug.cgi?id=1114732] from MODIFIED to POST
> S-RAMP allows artifacts to be created with invalid characters in the Artifact Type
> ----------------------------------------------------------------------------------
>
> Key: SRAMP-395
> URL: https://issues.jboss.org/browse/SRAMP-395
> Project: S-RAMP
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 0.4.0 - Tomcat Support
> Reporter: Eric Wittmann
> Assignee: Eric Wittmann
> Fix For: 0.5.0.Alpha1, 0.5.0
>
>
> There are two ways (I believe) that users can mistakenly create artifacts with an invalid artifact type. The first is via the CLI:
> {code}
> s-ramp:upload /path/to/file.ext "Invalid Type"
> s-ramp:create "Invalid Type" "Valid Artifact Name" "Description goes here."
> {code}
> The other is via the s-ramp UI's Import Artifact dialog. This dialog allows the user to type in any Artifact Type they want, which is an opportunity to mess it up.
> We need to make sure we have appropriate validation of any custom Artifact Type provided by the user on the server (probably in the REST layer).
> For bonus points we can add validation to the UI and CLI to prevent the request from even being made to the server unless it's valid.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months