[JBoss JIRA] (RTGOV-398) Check whether switchyard service supports resubmission of message
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-398?page=com.atlassian.jira.plugin.... ]
Gary Brown resolved RTGOV-398.
------------------------------
Resolution: Done
> Check whether switchyard service supports resubmission of message
> -----------------------------------------------------------------
>
> Key: RTGOV-398
> URL: https://issues.jboss.org/browse/RTGOV-398
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Components: User Interface
> Reporter: Gary Brown
> Assignee: Michael Clay
> Fix For: 2.0.0.Final
>
>
> To support message resubmission, a switchyard service must have a SCA binding and the target operation must be oneway.
> RTGOV-340 provides the mechanism for determining if a message can be resubmitted, and providing edit/resubmit support in the UI.
> This issue updates the SwitchYardServicesProvider to correctly determine if the target service type and operation supports message resubmission.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (RTGOV-461) Call trace includes activities from other conversations when using ESActivityStore
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-461?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-461:
----------------------------------
Also reproduced the issue with the following sequence:
1) clean out ES data folder
2) start ES server and EAP (with rtgov installed)
3) submit order3 request
4) submit order5bad request
5) check call trace for exception situation, which will show the single request for order 5, followed by trace for order 3
> Call trace includes activities from other conversations when using ESActivityStore
> ----------------------------------------------------------------------------------
>
> Key: RTGOV-461
> URL: https://issues.jboss.org/browse/RTGOV-461
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.0.0.Final
>
>
> When doing order1 followed by order3, the order1 violation produced a correct trace, but the order3 situations resulted in a call trace that also included the trace for order1.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (SRAMP-440) Add a final redirect filter to overlord SPs
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-440?page=com.atlassian.jira.plugin.... ]
Work on SRAMP-440 started by Brett Meyer.
> Add a final redirect filter to overlord SPs
> -------------------------------------------
>
> Key: SRAMP-440
> URL: https://issues.jboss.org/browse/SRAMP-440
> Project: S-RAMP
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: UI
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
> Fix For: 0.5.0.Final
>
>
> The IDP (when running in tomcat, jetty, fuse) causes the browser to do a POST of the SAML assertion to the SP (e.g. s-ramp-ui). This POST is consumed by the SPFilter and the assertion is consumed. At this point the user is authenticated and the UI is loaded.
> However, if the user then tries to refresh the page, the browser will likely ask if the user wishes to Resend data.
> To avoid this problem we should have a filter that does a final redirect (only after a POST to the SPFilter) so that the browser finishes up with a GET request to the UI rather than a POST.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years
[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:
-----------------------------------
Updated the description with all combined thoughts
> 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 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
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years
[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 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
was:
Create a new s-ramp-test module to contain all integration tests. Thoughts:
- 1 central abstract class 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.
- None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it.
Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the 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 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
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years
[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:
-----------------------------------
Thanks Gary. For now, we'll implement EAP similar to what you did for RTGov: require an installation to be unpacked, then set JBOSS_HOME. But eventually, once we have CI hardware within RH's network, we should also support automatically pulling it down. For Tomcat & Jetty, let's give automatically downloading the distros a shot. And yes, for Fuse, embedded.
> 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 abstract class 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.
> - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it.
> Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years
[JBoss JIRA] (SRAMP-431) Arquillian-based integration tests
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on SRAMP-431:
----------------------------------
Agree using managed containers would be good for all but fuse, to replicate the installation process as well. Areas to consider:
1) As Eric said, EAP cannot be downloaded, so we need to work out an alternative approach for obtaining this distribution. Although we will want to support WildFly at some point, it would be good to have EAP as a separate test.
2) RTGov requires Switchyard to also be installed - atleast for EAP - however this should just be a case of adding its installation as an additional step before running the integration tests.
3) For RTGov we will need to partition the integration tests, as there are groups of tests that use different deployments. Although this may not be an issue for SRAMP or DTGov, it would be good to factor this in to the design, so we use a common approach across the sub-projects.
> 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 abstract class 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.
> - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it.
> Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years