April 2015 - overlord-issues - Jboss List Archives

[JBoss JIRA] (RTGOV-650) A Situation is always resubmitted to localhost:8080

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-650?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-650: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/289 > A Situation is always resubmitted to localhost:8080 > --------------------------------------------------- > > Key: RTGOV-650 > URL: https://issues.jboss.org/browse/RTGOV-650 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: Documentation > Reporter: Werner Müller > Assignee: Gary Brown > Fix For: 2.1.0.Beta2 > > > A Situation is always resubmitted to localhost:8080. Instead, it should be resubmitted to the original target address of the request. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-650) A Situation is always resubmitted to localhost:8080

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-650?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-650: ----------------------------- Component/s: Documentation > A Situation is always resubmitted to localhost:8080 > --------------------------------------------------- > > Key: RTGOV-650 > URL: https://issues.jboss.org/browse/RTGOV-650 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: Documentation > Reporter: Werner Müller > Assignee: Gary Brown > Fix For: 2.1.0.Beta2 > > > A Situation is always resubmitted to localhost:8080. Instead, it should be resubmitted to the original target address of the request. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-650) A Situation is always resubmitted to localhost:8080

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-650?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-650: ---------------------------------- There already exists a property for providing a list of URLs, and it uses a round robin approach to distribute load. The issue is that this property was not included in the documentation - so I'll change this jira to be a documentation issue. Using the switchyard registry is something that could be explored as a separate enhancement, perhaps if this approach is limiting in some way. To test out the approach, specify a comma separated list of URLs in the overlord-rtgov.properties against a property called "SwitchYardServicesProvider.serverURLs". > A Situation is always resubmitted to localhost:8080 > --------------------------------------------------- > > Key: RTGOV-650 > URL: https://issues.jboss.org/browse/RTGOV-650 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Werner Müller > Assignee: Gary Brown > Fix For: 2.1.0.Beta2 > > > A Situation is always resubmitted to localhost:8080. Instead, it should be resubmitted to the original target address of the request. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-650) A Situation is always resubmitted to localhost:8080

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-650?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-650: ----------------------------- Fix Version/s: 2.1.0.Beta2 > A Situation is always resubmitted to localhost:8080 > --------------------------------------------------- > > Key: RTGOV-650 > URL: https://issues.jboss.org/browse/RTGOV-650 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Werner Müller > Assignee: Gary Brown > Fix For: 2.1.0.Beta2 > > > A Situation is always resubmitted to localhost:8080. Instead, it should be resubmitted to the original target address of the request. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-651) Add a Refresh button to Resubmit Failures tab

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-651?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-651: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/287, https://github.com/Governance/rtgov/pull/288 (was: https://github.com/Governance/rtgov/pull/287) > Add a Refresh button to Resubmit Failures tab > --------------------------------------------- > > Key: RTGOV-651 > URL: https://issues.jboss.org/browse/RTGOV-651 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Werner Müller > Assignee: Gary Brown > Priority: Minor > Fix For: 2.1.0.Beta2 > > > A Refresh button is missing on the "Resubmit Failures" tab, as it is available on the "Situations" page. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-652) Sortable columns on Resubmit Failures tab

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-652?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-652: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/287, https://github.com/Governance/rtgov/pull/288 (was: https://github.com/Governance/rtgov/pull/287) > Sortable columns on Resubmit Failures tab > ----------------------------------------- > > Key: RTGOV-652 > URL: https://issues.jboss.org/browse/RTGOV-652 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Werner Müller > Assignee: Gary Brown > Fix For: 2.1.0.Beta2 > > > The columns on the "Resubmit Failures" tab should be sortable, as they are on the "Situations" page. > The default sort order should be the same as the default sort order on the "Situations" page (currently descending by Timestamp). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-652) Sortable columns on Resubmit Failures tab

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-652?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-652. ------------------------------ Resolution: Done > Sortable columns on Resubmit Failures tab > ----------------------------------------- > > Key: RTGOV-652 > URL: https://issues.jboss.org/browse/RTGOV-652 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Werner Müller > Assignee: Gary Brown > Fix For: 2.1.0.Beta2 > > > The columns on the "Resubmit Failures" tab should be sortable, as they are on the "Situations" page. > The default sort order should be the same as the default sort order on the "Situations" page (currently descending by Timestamp). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-651) Add a Refresh button to Resubmit Failures tab

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-651?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-651. ------------------------------ Resolution: Done > Add a Refresh button to Resubmit Failures tab > --------------------------------------------- > > Key: RTGOV-651 > URL: https://issues.jboss.org/browse/RTGOV-651 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Werner Müller > Assignee: Gary Brown > Priority: Minor > Fix For: 2.1.0.Beta2 > > > A Refresh button is missing on the "Resubmit Failures" tab, as it is available on the "Situations" page. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ] Brett Meyer edited comment on ARTIF-674 at 4/9/15 11:31 AM: ------------------------------------------------------------ However, I suppose the spec is vague enough that there's no reason that we couldn't take this approach: Maintain conformance, but in a "separated" fashion (separate Atom binding, but the "core" binding becomes JSON, etc.). The new "core" binding is the main driving force behind all this. Every time I add a new feature that's outside of the spec requirements, I have to somehow get it to fit into the Atom binding so that the interfaces can use it. It almost always ends up being extremely hacky. We'd also maintain the /ext model for ad-hoc support, but go ahead and add the new extension plugin architecture. As long as its all *additive*, maybe it'd be worthwhile. was (Author: brmeyer): However, I suppose the spec is vague enough that there's no reason that we couldn't take this approach: Maintain conformance, but in a "separated" fashion (separate Atom binding, but the "core" binding becomes JSON, etc.). We'd also maintain the /ext model for ad-hoc support, but go ahead and add the new extension plugin architecture. As long as its all *additive*, maybe it'd be worthwhile. > Separate from the S-RAMP spec > ----------------------------- > > Key: ARTIF-674 > URL: https://issues.jboss.org/browse/ARTIF-674 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 2.0 > > > For 2.0, we might consider separating from the S-RAMP spec. IMO, the spec should be largely considered dead and abandoned. RH seems to be the only entity still "using" it. Further, many pieces are starting to hold things back, in addition to adding needless complexity. Instead of focusing on conformance, use only "the good parts". Claim that the project is "loosely based on S-RAMP". > Ideas: > REMOVE > - Atom binding: Instead, use pure JSON REST > - The web UI services: With the server services using JSON REST, we'd no longer need an additional service layer specifically for the web UI. > - All "s-ramp" namespaces > KEEP > - Model schemas and bindings. > - Query core syntax -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.... ] Gary Brown commented on ARTIF-674: ---------------------------------- Comments overlapping :) +1 to additive changes. > Separate from the S-RAMP spec > ----------------------------- > > Key: ARTIF-674 > URL: https://issues.jboss.org/browse/ARTIF-674 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 2.0 > > > For 2.0, we might consider separating from the S-RAMP spec. IMO, the spec should be largely considered dead and abandoned. RH seems to be the only entity still "using" it. Further, many pieces are starting to hold things back, in addition to adding needless complexity. Instead of focusing on conformance, use only "the good parts". Claim that the project is "loosely based on S-RAMP". > Ideas: > REMOVE > - Atom binding: Instead, use pure JSON REST > - The web UI services: With the server services using JSON REST, we'd no longer need an additional service layer specifically for the web UI. > - All "s-ramp" namespaces > KEEP > - Model schemas and bindings. > - Query core syntax -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues April 2015