[JBoss JIRA] (SWSQE-669) Checklist for custom fields in order to support existing and future workflows for KIALI
by Prachi Yadav (Jira)
Prachi Yadav created SWSQE-669:
----------------------------------
Summary: Checklist for custom fields in order to support existing and future workflows for KIALI
Key: SWSQE-669
URL: https://issues.jboss.org/browse/SWSQE-669
Project: Kiali QE
Issue Type: QE Task
Reporter: Prachi Yadav
project MUST have the following custom fields in order to support existing and future workflows and visualizations:
QE Test Coverage with values +, -, and ? (Null is supported)
SFDC Cases Counter
SFDC Cases Links
These custom fields must exist as above so that we do not need to customize logic for any one-offs. The SFDC Cases * fields are there to support "integration" with our SalesForce system used by CEE/GSS for customer cases and the links here are links to SFDC customer cases.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (SWSQE-668) Checklist for custom fields in order to support existing and future workflows for Istio
by Prachi Yadav (Jira)
Prachi Yadav created SWSQE-668:
----------------------------------
Summary: Checklist for custom fields in order to support existing and future workflows for Istio
Key: SWSQE-668
URL: https://issues.jboss.org/browse/SWSQE-668
Project: Kiali QE
Issue Type: QE Task
Reporter: Prachi Yadav
project MUST have the following custom fields in order to support existing and future workflows and visualizations:
QE Test Coverage with values +, -, and ? (Null is supported)
SFDC Cases Counter
SFDC Cases Links
These custom fields must exist as above so that we do not need to customize logic for any one-offs. The SFDC Cases * fields are there to support "integration" with our SalesForce system used by CEE/GSS for customer cases and the links here are links to SFDC customer cases.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (JGRP-2337) DiagnosticsHandler without reflection
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2337?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2337:
---------------------------
Description:
Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
Investigate creating a {{ProbeHandler}} for {{"jmx"}} and {{"op"}} commands, which does not use reflection. 2 alternatives come to mind:
* Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
* Point to a running stack. The code uses reflection (obviously this needs to run in non-native mode) to generate the native {{ProbeHandler}} from the list of protocols running in the current stack. This code can then be compiled and used in native image generation.
was:
Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
Investigate creating a {{ProbeHandler}} for {{"jmx""}} and {{"op"}} commands, which does not use reflection. 2 alternatives come to mind:
* Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
* Point to a running stack. The code uses reflection (obviously this needs to run in non-native mode) to generate the native {{ProbeHandler}} from the list of protocols running in the current stack. This code can then be compiled and used in native image generation.
> DiagnosticsHandler without reflection
> -------------------------------------
>
> Key: JGRP-2337
> URL: https://issues.jboss.org/browse/JGRP-2337
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
> However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
> Investigate creating a {{ProbeHandler}} for {{"jmx"}} and {{"op"}} commands, which does not use reflection. 2 alternatives come to mind:
> * Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
> * Point to a running stack. The code uses reflection (obviously this needs to run in non-native mode) to generate the native {{ProbeHandler}} from the list of protocols running in the current stack. This code can then be compiled and used in native image generation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (SWSQE-667) Checklist for custom fields in order to support existing and future workflows for Jaeger
by Prachi Yadav (Jira)
Prachi Yadav created SWSQE-667:
----------------------------------
Summary: Checklist for custom fields in order to support existing and future workflows for Jaeger
Key: SWSQE-667
URL: https://issues.jboss.org/browse/SWSQE-667
Project: Kiali QE
Issue Type: QE Task
Reporter: Prachi Yadav
project MUST have the following custom fields in order to support existing and future workflows and visualizations:
QE Test Coverage with values +, -, and ? (Null is supported)
SFDC Cases Counter
SFDC Cases Links
These custom fields must exist as above so that we do not need to customize logic for any one-offs. The SFDC Cases * fields are there to support "integration" with our SalesForce system used by CEE/GSS for customer cases and the links here are links to SFDC customer cases.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (JGRP-2337) DiagnosticsHandler without reflection
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2337?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2337:
---------------------------
Description:
Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
Investigate creating a {{ProbeHandler}} for {{"jmx""}} and {{"op"}} commands, which does not use reflection. 2 alternatives come to mind:
* Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
* Point to a running stack. The code uses reflection (obviously this needs to run in non-native mode) to generate the native {{ProbeHandler}} from the list of protocols running in the current stack. This code can then be compiled and used in native image generation.
was:
Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
Investigate creating a {{ProbeHandler}} for {{"jmx""}} and {{"op"}} commands, which does not use reflection.
Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
> DiagnosticsHandler without reflection
> -------------------------------------
>
> Key: JGRP-2337
> URL: https://issues.jboss.org/browse/JGRP-2337
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
> However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
> Investigate creating a {{ProbeHandler}} for {{"jmx""}} and {{"op"}} commands, which does not use reflection. 2 alternatives come to mind:
> * Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
> * Point to a running stack. The code uses reflection (obviously this needs to run in non-native mode) to generate the native {{ProbeHandler}} from the list of protocols running in the current stack. This code can then be compiled and used in native image generation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (DROOLS-3341) Duplicate DO columns
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3341?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-3341:
--------------------------------------
[~a175335], I think that "duplicate column" proposed here is a misleading caption; I would rather use "duplicate instance", as the user is not actually duplicating one single column, but potentially multiple (two, three, four and more) columns of one single instance. What do you think?
!1.png|thumbnail!
> Duplicate DO columns
> --------------------
>
> Key: DROOLS-3341
> URL: https://issues.jboss.org/browse/DROOLS-3341
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: 1.png, duplicate.png, multiDO.png
>
>
> As a user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
> * As a user I want a means to create a data object instance in the test template using an existing statement column, so that I can quickly create instances from the test table.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (DROOLS-3341) Duplicate DO columns
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3341?page=com.atlassian.jira.plugi... ]
Klara Kufova updated DROOLS-3341:
---------------------------------
Attachment: 1.png
> Duplicate DO columns
> --------------------
>
> Key: DROOLS-3341
> URL: https://issues.jboss.org/browse/DROOLS-3341
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: 1.png, duplicate.png, multiDO.png
>
>
> As a user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
> * As a user I want a means to create a data object instance in the test template using an existing statement column, so that I can quickly create instances from the test table.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (JGRP-2337) DiagnosticsHandler without reflection
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2337?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2337:
---------------------------
Description:
Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
Investigate creating a {{ProbeHandler}} for {{"jmx""}} and {{"op"}} commands, which does not use reflection.
Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
was:
Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{op}} and {{jmx}} commands are handled via reflection.
However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
Investigate creating a {{ProbeHandler}} for {{"jmx""}} and {{"op"}} commands, which does not use reflection.
Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
> DiagnosticsHandler without reflection
> -------------------------------------
>
> Key: JGRP-2337
> URL: https://issues.jboss.org/browse/JGRP-2337
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
> However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
> Investigate creating a {{ProbeHandler}} for {{"jmx""}} and {{"op"}} commands, which does not use reflection.
> Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (JGRP-2337) DiagnosticsHandler without reflection
by Bela Ban (Jira)
Bela Ban created JGRP-2337:
------------------------------
Summary: DiagnosticsHandler without reflection
Key: JGRP-2337
URL: https://issues.jboss.org/browse/JGRP-2337
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.1.0
Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{op}} and {{jmx}} commands are handled via reflection.
However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
Investigate creating a {{ProbeHandler}} for {{"jmx""}} and {{"op"}} commands, which does not use reflection.
Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months