March 2015 - overlord-issues - Jboss List Archives

[JBoss JIRA] (RTGOV-645) Resubmitted message should identify source situation to enable further failures (situations) to be linked back

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-645?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-645: ---------------------------------- It may be possible (for now) to just assume that only one situation will be created from resubmit failure, and if multiple get created, then only the most recent of those will be candidate for further resubmit. However that leaves one issue - if there is some way to show this list of child situations by expanding the root situation, then it means that to do a further resubmit the user needs to (a) expand the root node, and (b) locate the last situation in the list and navigate to it. Are you ok with this? Possibly the child situations should be in reverse order, so most recent first? > Resubmitted message should identify source situation to enable further failures (situations) to be linked back > -------------------------------------------------------------------------------------------------------------- > > Key: RTGOV-645 > URL: https://issues.jboss.org/browse/RTGOV-645 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.2.0 > > > When a message, associated with a situation, is resubmitted, ensure that the situation id is carried in a message header so that it can be included in resulting activity events. > If the resubmitted message results in further situations being created, then these new situations should include the reference back to the originating situation id. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-464) Docker image

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-464?page=com.atlassian.jira.plugin.... ] Brett Meyer updated ARTIF-464: ------------------------------ Git Pull Request: https://github.com/ArtificerRepo/artificer/pull/516 > Docker image > ------------ > > Key: ARTIF-464 > URL: https://issues.jboss.org/browse/ARTIF-464 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-645) Resubmitted message should identify source situation to enable further failures (situations) to be linked back

by Michael Ilger (JIRA)

[ https://issues.jboss.org/browse/RTGOV-645?page=com.atlassian.jira.plugin.... ] Michael Ilger commented on RTGOV-645: ------------------------------------- Hi Gary, You are correct that our assumption is that only one single new situation would be created. I wonder if it would make sense to set up a quick call to discuss our requirements and map them to the generic requirements you see. Doing this in email or ticket comments would probably make this an unnecessarily long process. > Resubmitted message should identify source situation to enable further failures (situations) to be linked back > -------------------------------------------------------------------------------------------------------------- > > Key: RTGOV-645 > URL: https://issues.jboss.org/browse/RTGOV-645 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.2.0 > > > When a message, associated with a situation, is resubmitted, ensure that the situation id is carried in a message header so that it can be included in resulting activity events. > If the resubmitted message results in further situations being created, then these new situations should include the reference back to the originating situation id. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-645) Resubmitted message should identify source situation to enable further failures (situations) to be linked back

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-645?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-645: ---------------------------------- Hi Michael - thanks for the additional information. It might be best to take one point at a time - so firstly want to concentrate on the resubmission failure and what could occur. In your description I believe there is an assumption that failure of a resubmission will result in a single further situation - and therefore if this was the case, your description of only the 'newest' situation being resubmitted again makes sense. However what happens if when the resubmitted message fails it results in multiple further situations being created? And due to the async nature of the system, there is no guarantee in which order these new situations would be created? > Resubmitted message should identify source situation to enable further failures (situations) to be linked back > -------------------------------------------------------------------------------------------------------------- > > Key: RTGOV-645 > URL: https://issues.jboss.org/browse/RTGOV-645 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.2.0 > > > When a message, associated with a situation, is resubmitted, ensure that the situation id is carried in a message header so that it can be included in resulting activity events. > If the resubmitted message results in further situations being created, then these new situations should include the reference back to the originating situation id. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-645) Resubmitted message should identify source situation to enable further failures (situations) to be linked back

by Michael Ilger (JIRA)

[ https://issues.jboss.org/browse/RTGOV-645?page=com.atlassian.jira.plugin.... ] Michael Ilger commented on RTGOV-645: ------------------------------------- Hi Gary, Regarding your questions: Represent situations in a tree representing the resubmission failures: This could lead to usability problems, as the user has to do a lot of extra navigation to get the details of all situations. Additionally there are also bulk actions and filters to keep in mind. The root node shows the number of resubmits so far (this is equal to the number of child nodes): Showing the total of child nodes sounds like a reasonable approach to just give the user a feeling of the overall amount of data connected. Only the newest situation in a tree is allowed to be resubmitted: From our point of view the newest situation can always be retried (also multiple times, given that it stays the newest situation) [..]Either the tree is fully shown or hidden: This really depends on the definition of leaf node, and what we expect the tree to look like. Our assumption is that all resubmissions are immediate children of the original message, which gives us a tree of depth 1 with a lot of leaves. > Resubmitted message should identify source situation to enable further failures (situations) to be linked back > -------------------------------------------------------------------------------------------------------------- > > Key: RTGOV-645 > URL: https://issues.jboss.org/browse/RTGOV-645 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.2.0 > > > When a message, associated with a situation, is resubmitted, ensure that the situation id is carried in a message header so that it can be included in resulting activity events. > If the resubmitted message results in further situations being created, then these new situations should include the reference back to the originating situation id. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-467) UI: relationship visualizations

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-467?page=com.atlassian.jira.plugin.... ] Brett Meyer edited comment on ARTIF-467 at 3/17/15 11:27 PM: ------------------------------------------------------------- A few ideas from the examples: UNIDIRECTIONAL http://charts.animateddata.co.uk/datavistree & http://mbostock.github.io/d3/talk/20111018/tree.html http://bl.ocks.org/mbostock/1093025 http://bl.ocks.org/Neilos/584b9a5d44d5fe00f779 http://visjs.org/examples/network/23_hierarchical_layout.html BIDIRECTIONAL http://www.redotheweb.com/DependencyWheel/ was (Author: brmeyer): A few D3 ideas: UNIDIRECTIONAL http://charts.animateddata.co.uk/datavistree & http://mbostock.github.io/d3/talk/20111018/tree.html http://bl.ocks.org/mbostock/1093025 http://bl.ocks.org/Neilos/584b9a5d44d5fe00f779 BIDIRECTIONAL http://www.redotheweb.com/DependencyWheel/ > UI: relationship visualizations > ------------------------------- > > Key: ARTIF-467 > URL: https://issues.jboss.org/browse/ARTIF-467 > Project: Artificer > Issue Type: Feature Request > Components: UI > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-467) UI: relationship visualizations

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-467?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on ARTIF-467: ----------------------------------- A few D3 ideas: UNIDIRECTIONAL http://charts.animateddata.co.uk/datavistree & http://mbostock.github.io/d3/talk/20111018/tree.html http://bl.ocks.org/mbostock/1093025 http://bl.ocks.org/Neilos/584b9a5d44d5fe00f779 BIDIRECTIONAL http://www.redotheweb.com/DependencyWheel/ > UI: relationship visualizations > ------------------------------- > > Key: ARTIF-467 > URL: https://issues.jboss.org/browse/ARTIF-467 > Project: Artificer > Issue Type: Feature Request > Components: UI > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-663) UI: Delete Artifact is broken

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-663?page=com.atlassian.jira.plugin.... ] Brett Meyer resolved ARTIF-663. ------------------------------- Resolution: Done > UI: Delete Artifact is broken > ----------------------------- > > Key: ARTIF-663 > URL: https://issues.jboss.org/browse/ARTIF-663 > Project: Artificer > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Alpha2 > > > Deleting an artifact, through the UI's artifact details view, is broken: > "org.jboss.errai.enterprise.client.jaxrs.api.ResponseException: Unsupported Media Type" > When correcting, think through how constraint violations should look. Maybe just throw it and let the error message come up? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-663) UI: Delete Artifact is broken

by Brett Meyer (JIRA)

Brett Meyer created ARTIF-663: --------------------------------- Summary: UI: Delete Artifact is broken Key: ARTIF-663 URL: https://issues.jboss.org/browse/ARTIF-663 Project: Artificer Issue Type: Bug Reporter: Brett Meyer Assignee: Brett Meyer Deleting an artifact, through the UI's artifact details view, is broken: "org.jboss.errai.enterprise.client.jaxrs.api.ResponseException: Unsupported Media Type" When correcting, think through how constraint violations should look. Maybe just throw it and let the error message come up? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-663) UI: Delete Artifact is broken

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-663?page=com.atlassian.jira.plugin.... ] Brett Meyer updated ARTIF-663: ------------------------------ Fix Version/s: 1.1.0.Final 1.0.0.Alpha2 > UI: Delete Artifact is broken > ----------------------------- > > Key: ARTIF-663 > URL: https://issues.jboss.org/browse/ARTIF-663 > Project: Artificer > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Alpha2 > > > Deleting an artifact, through the UI's artifact details view, is broken: > "org.jboss.errai.enterprise.client.jaxrs.api.ResponseException: Unsupported Media Type" > When correcting, think through how constraint violations should look. Maybe just throw it and let the error message come up? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues March 2015