[JBoss JIRA] (RTGOV-652) Sortable columns on Resubmit Failures tab
by Werner Müller (JIRA)
Werner Müller created RTGOV-652:
-----------------------------------
Summary: 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
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, 8 months
[JBoss JIRA] (RTGOV-651) Add a Refresh button to Resubmit Failures tab
by Werner Müller (JIRA)
Werner Müller created RTGOV-651:
-----------------------------------
Summary: 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
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, 8 months
[JBoss JIRA] (RTGOV-650) A Situation is always resubmitted to localhost:8080
by Werner Müller (JIRA)
Werner Müller created RTGOV-650:
-----------------------------------
Summary: 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
Environment: A Situation is always resubmitted to localhost:8080. Instead, it should be resubmitted to the original target address of the request.
Reporter: Werner Müller
Assignee: Gary Brown
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (RTGOV-649) Status handling for Situations
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-649?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-649:
----------------------------------
As mentioned on the call, this automated approach will only be possible if the resubmit client gets notified of the error - i.e. as a synchronous response to the resubmitted service call.
So for example, the situation may be resubmitted, and the service call does not return an exception - indicating that the service call worked. This will be used to set the status to RESOLVED. However later on, when the activity information is reported to the server, an EPN processes the information and determines a problem occurred, and creates a new Situation. This Situation will be a child of the resubmitting situation, but the status would have already been changed to RESOLVED.
If this is going to be a problem, then the only option would be for the EPN creating the situation to also have additional logic to 're-open' the parent situation. Is this required?
> Status handling for Situations
> ------------------------------
>
> Key: RTGOV-649
> URL: https://issues.jboss.org/browse/RTGOV-649
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Reporter: Werner Müller
> Assignee: Gary Brown
>
> This relates to https://issues.jboss.org/browse/RTGOV-645. To support the Resubmit feature, the handling of the Situation's Status field shall be changed:
> - Only 3 Status values shall be available: UNRESOLVED, IN PROGRESS, RESOLVED:
> Either remove other values, or provide means to configure the values.
> - The default entry for the Status filter on the Situations page shall be (the new value) OPEN:
> This includes all Status values other than RESOLVED.
>
> - A Situation's Status should be changed only programmatically (see below):
> Either remove the status change buttons on the "Details" tab or provide means to hide them by configuration.
>
> - The "Assign" button shall be available all the time. It potentially overwrites an existing value for 'assignedTo'.
> (This is to be consistent with the resubmit behaviour as defined below.)
> - The initial state of a (root) Situation is UNRESOLVED.
> When a Situation is resubmitted:
> (1) 'assignedTo' is set to the current user (overriding the current value)
> (2a) If no failure is encountered (no child situation is created),
> the Status is changed to RESOLVED.
> (2b) If a failure is encountered (and a child situation is created),
> the Status is changed to IN_PROGRESS.
> - A Situation in Status RESOLVED must not be resubmitted anymore:
> (1) The Resubmit button on the "Message" tab is disabled.
> (2) The Situation is excluded from a bulk resubmit.
>
> As already stated in the requirements for RTGOV-645, assignedTo and Status shall have the same value for all Situations in a "resubmit tree".
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[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:
----------------------------------
I've numbered the responses to help track the individual issues in further comments:
(1) "A Situation is always resubmitted to localhost:8080. Instead, it should be resubmitted to the original target address of the request."
Can you create a separate jira for this. The problem is that currently this information is not captured - will need to consult the switchyard team to see what is possible,
(2) "Resubmitting a SoapFault (generating the same SoapFault) creates a new root Situation, instead of a "Resubmit Failure" (child).
(A SoapFault situation in our case is created based on the existence of the 'soap_fault_info' property,
and not because of an Exception in the message.)"
Does the EPN that creates the situation add the properties from the request into the situation? (See the sample ordermgmt/epn)
(3) "Scenario:
A request is received which triggers a SchemaValidationException. The request has no Security element.
A failure Situation is created for the Schema Validation error.
The schema error is corrected and the Situation is resubmitted.
A "Required policies missing" Exception is generated for the missing Security element.
Error: This 2nd Exception is shown as new root Situation, not as a "Resubmit Failure" (child)."
The security issue may need to be investigated by the switchyard team - could you create a separate jira for this and if possible attach the swyd app (or atleast the switchyard.xml). Can you also attach the epn that creates the situation.
(4) Bulk vs individual resubmit - found this problem after further testing and has now been fixed.
(5) "A newly created child situation should have the same Status as its ancestor.
Currently it is created in Status UNRESOLVED."
This should be working - can you try the ordermgmt sample, submitting "mvn exec:java -Dreq=order5bad", which should result in a schema error being reported as exception, change the situation status (and assign), and then resubmit, letting me know whether the resulting child situation is UNRESOLVED or not? If it is not UNRESOLVED, then we need to examine what the differences are between your app and the sample.
(6)/(8)/(9) - Can you create a jira for this.
(7) - tooltip text change shouldn't be a problem
(10) - persistence filter - can you create a separate jira for this as well please.
> 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.1.0.Beta2
>
>
> 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, 8 months
[JBoss JIRA] (RTGOV-649) Status handling for Situations
by Werner Müller (JIRA)
Werner Müller created RTGOV-649:
-----------------------------------
Summary: Status handling for Situations
Key: RTGOV-649
URL: https://issues.jboss.org/browse/RTGOV-649
Project: RTGov (Run Time Governance)
Issue Type: Feature Request
Reporter: Werner Müller
Assignee: Gary Brown
This relates to https://issues.jboss.org/browse/RTGOV-645. To support the Resubmit feature, the handling of the Situation's Status field shall be changed:
- Only 3 Status values shall be available: UNRESOLVED, IN PROGRESS, RESOLVED:
Either remove other values, or provide means to configure the values.
- The default entry for the Status filter on the Situations page shall be (the new value) OPEN:
This includes all Status values other than RESOLVED.
- A Situation's Status should be changed only programmatically (see below):
Either remove the status change buttons on the "Details" tab or provide means to hide them by configuration.
- The "Assign" button shall be available all the time. It potentially overwrites an existing value for 'assignedTo'.
(This is to be consistent with the resubmit behaviour as defined below.)
- The initial state of a (root) Situation is UNRESOLVED.
When a Situation is resubmitted:
(1) 'assignedTo' is set to the current user (overriding the current value)
(2a) If no failure is encountered (no child situation is created),
the Status is changed to RESOLVED.
(2b) If a failure is encountered (and a child situation is created),
the Status is changed to IN_PROGRESS.
- A Situation in Status RESOLVED must not be resubmitted anymore:
(1) The Resubmit button on the "Message" tab is disabled.
(2) The Situation is excluded from a bulk resubmit.
As already stated in the requirements for RTGOV-645, assignedTo and Status shall have the same value for all Situations in a "resubmit tree".
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (RTGOV-645) Resubmitted message should identify source situation to enable further failures (situations) to be linked back
by Werner Müller (JIRA)
[ https://issues.jboss.org/browse/RTGOV-645?page=com.atlassian.jira.plugin.... ]
Werner Müller commented on RTGOV-645:
-------------------------------------
When testing the community edition http://downloads.jboss.org/overlord/tmp/overlord-rtgov-2.0.2-SNAPSHOT.zip, we found the following issues:
- A Situation is always resubmitted to localhost:8080. Instead, it should be resubmitted to the original target address of the request.
- Resubmitting a SoapFault (generating the same SoapFault) creates a new root Situation, instead of a "Resubmit Failure" (child).
(A SoapFault situation in our case is created based on the existence of the 'soap_fault_info' property,
and not because of an Exception in the message.)
- Scenario:
A request is received which triggers a SchemaValidationException. The request has no Security element.
A failure Situation is created for the Schema Validation error.
The schema error is corrected and the Situation is resubmitted.
A "Required policies missing" Exception is generated for the missing Security element.
Error: This 2nd Exception is shown as new root Situation, not as a "Resubmit Failure" (child).
- Scenario:
Several failure Situations are resubmitted with the bulk action.
As there was no change in the message, all of them end with the original failure.
Error:
For each one of those Situations, a new root Situation is displayed instead of a "Resubmit Failure" (child).
However:
If the Situations are resubmitted individually via the Resubmit button on the "Message" tab,
the "Resubmit Failure" (child) is properly created.
If one of the Situations resubmitted in bulk already has children,
the new failure Situation is correctly shown as child situation.
- A newly created child situation should have the same Status as its ancestor.
Currently it is created in Status UNRESOLVED.
- A Refresh button is missing on the "Resubmit Failures" tab, as it is available on the "Situations" page.
- For consistency reasons, the hover text over the bulk "Retry" button should say "Resubmit".
- The "Resubmit Failures" tab should contain a refresh button, as it is on the "Situations" page.
- (The following is a a change to the original requirement. It came up because we now have list views instead of a tree view.)
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).
- The filter criteria on the "Situations" page should be preserved during the session.
Currently they are cleared when you navigate away from that page.
> 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.1.0.Beta2
>
>
> 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, 8 months
[JBoss JIRA] (ARTIF-673) Create a stripped-down distro for use on any app server
by Brett Meyer (JIRA)
Brett Meyer created ARTIF-673:
---------------------------------
Summary: Create a stripped-down distro for use on any app server
Key: ARTIF-673
URL: https://issues.jboss.org/browse/ARTIF-673
Project: Artificer
Issue Type: Feature Request
Reporter: Brett Meyer
Assignee: Brett Meyer
Realistically, there should be no reason why we couldn't rely on embedded modeshape, simple BASIC auth, etc. for a really stripped-down distro. Think of it as a simplified "headless" mode of sorts.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months