June 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (RTGOV-490) Refactor to better support multiple installation targets

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-490?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-490. ------------------------------ Resolution: Done > Refactor to better support multiple installation targets > -------------------------------------------------------- > > Key: RTGOV-490 > URL: https://issues.jboss.org/browse/RTGOV-490 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Aim is to create a single distribution that will contain an installer for all supported platforms. > Subject to changes in the overlord-commons installer, to setup the target environment, the rtgov installer should apply additional changes to the target location. > As part of this refactor, the integration tests should be moved out into a separate top level folder - aim will be to support integration testing across all supported platform from the same set of arquillian tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-490) Refactor to better support multiple installation targets

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-490?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-490: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/114 > Refactor to better support multiple installation targets > -------------------------------------------------------- > > Key: RTGOV-490 > URL: https://issues.jboss.org/browse/RTGOV-490 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Aim is to create a single distribution that will contain an installer for all supported platforms. > Subject to changes in the overlord-commons installer, to setup the target environment, the rtgov installer should apply additional changes to the target location. > As part of this refactor, the integration tests should be moved out into a separate top level folder - aim will be to support integration testing across all supported platform from the same set of arquillian tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-471) Maven Facade: Implement maven deploy support

by Eric Wittmann (JIRA)

Eric Wittmann created SRAMP-471: ----------------------------------- Summary: Maven Facade: Implement maven deploy support Key: SRAMP-471 URL: https://issues.jboss.org/browse/SRAMP-471 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Components: S-RAMP API Reporter: Eric Wittmann Assignee: David virgil naranjo Fix For: 0.5.0.Final The maven facade currently only supports maven GET related operations (e.g. pulling artifacts out of s-ramp using the standard maven http protocol support). We should enhance the facade to also support the maven PUT/POST http protocol. In other words, support whatever maven does when you do this: {code} mvn deploy {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-470) Maven Facade: Improve authentication

by Eric Wittmann (JIRA)

Eric Wittmann created SRAMP-470: ----------------------------------- Summary: Maven Facade: Improve authentication Key: SRAMP-470 URL: https://issues.jboss.org/browse/SRAMP-470 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Components: S-RAMP API Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: 0.5.0.Final Currently the maven facade requires authentication because we do not have a mechanism for providing selective read-only access to the JCR repository. However, the Maven Facade should be a read-only (for Maven GET operations) window into the s-ramp data. We need to do two things: 1) If the Maven Facade Request has authentication credentials associated with it, use them to log into the s-ramp repository 2) If the Maven Facade Request does *not* have authentication credentials associated with it, then log into JCR using read-only credentials -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-434) Upgrade overlord-commons-services to use ServiceTracker in the osgi impl

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-434?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-434: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > Upgrade overlord-commons-services to use ServiceTracker in the osgi impl > ------------------------------------------------------------------------ > > Key: SRAMP-434 > URL: https://issues.jboss.org/browse/SRAMP-434 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > Currently I'm going straight for the service refs in the osgi registry. Instead we should use ServiceTracker. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-434) Upgrade overlord-commons-services to use ServiceTracker in the osgi impl

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-434?page=com.atlassian.jira.plugin.... ] Eric Wittmann reassigned SRAMP-434: ----------------------------------- Assignee: David virgil naranjo (was: Eric Wittmann) > Upgrade overlord-commons-services to use ServiceTracker in the osgi impl > ------------------------------------------------------------------------ > > Key: SRAMP-434 > URL: https://issues.jboss.org/browse/SRAMP-434 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > Currently I'm going straight for the service refs in the osgi registry. Instead we should use ServiceTracker. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-440) Add a final redirect filter to overlord SPs

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-440?page=com.atlassian.jira.plugin.... ] Eric Wittmann closed SRAMP-440. ------------------------------- > 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.6#6264)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-440) Add a final redirect filter to overlord SPs

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-440?page=com.atlassian.jira.plugin.... ] Eric Wittmann resolved SRAMP-440. --------------------------------- Resolution: Done > 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.6#6264)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-452) Enhance s-ramp CLI property interpolation: support default values

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-452?page=com.atlassian.jira.plugin.... ] Eric Wittmann closed SRAMP-452. ------------------------------- > Enhance s-ramp CLI property interpolation: support default values > ------------------------------------------------------------------ > > Key: SRAMP-452 > URL: https://issues.jboss.org/browse/SRAMP-452 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Currently the shell supports property interpolation so that variables can be used in CLI command files. This takes the following form (for example): > {code} > connect http://localhost:8080/s-ramp ${username} ${password} > {code} > The CLI can then be invoked like this: > {code} > sramp.sh -f path/to/cli.txt -Dusername=admin -Dpassword=adminp > {code} > This is good, but let's also support optional default values for the variables, like this: > {code} > connect http://localhost:8080/s-ramp ${username:admin} ${password:adminp} > {code} > This will continue to replace ${username} with whatever value is passed via -Dusername=blah. However, if -Dusername is *not* provided, then the default value of 'admin' will be used. This will result in more powerful CLI scripts with commands like this: > {code} > connect ${sramp.endpoint:http://localhost:8080/s-ramp} ${sramp.username:admin} ${sramp.password:adminp} > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-452) Enhance s-ramp CLI property interpolation: support default values

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-452?page=com.atlassian.jira.plugin.... ] Eric Wittmann resolved SRAMP-452. --------------------------------- Resolution: Done > Enhance s-ramp CLI property interpolation: support default values > ------------------------------------------------------------------ > > Key: SRAMP-452 > URL: https://issues.jboss.org/browse/SRAMP-452 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Currently the shell supports property interpolation so that variables can be used in CLI command files. This takes the following form (for example): > {code} > connect http://localhost:8080/s-ramp ${username} ${password} > {code} > The CLI can then be invoked like this: > {code} > sramp.sh -f path/to/cli.txt -Dusername=admin -Dpassword=adminp > {code} > This is good, but let's also support optional default values for the variables, like this: > {code} > connect http://localhost:8080/s-ramp ${username:admin} ${password:adminp} > {code} > This will continue to replace ${username} with whatever value is passed via -Dusername=blah. However, if -Dusername is *not* provided, then the default value of 'admin' will be used. This will result in more powerful CLI scripts with commands like this: > {code} > connect ${sramp.endpoint:http://localhost:8080/s-ramp} ${sramp.username:admin} ${sramp.password:adminp} > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues June 2014