[JBoss JIRA] (WFLY-1415) Move away from expensive enum switch
by Lukas Vydra (Jira)
[ https://issues.redhat.com/browse/WFLY-1415?page=com.atlassian.jira.plugin... ]
Lukas Vydra commented on WFLY-1415:
-----------------------------------
Hi, is this issue still active? If so, I could start working on it.
> Move away from expensive enum switch
> ------------------------------------
>
> Key: WFLY-1415
> URL: https://issues.redhat.com/browse/WFLY-1415
> Project: WildFly
> Issue Type: Task
> Reporter: David Lloyd
> Priority: Minor
> Labels: janitor
>
> We use enums and enum switch extensively. These constructs generate many, many additional classes and bloat the code base unnecessarily.
> All cases where we are using enum-based switches for our XML parsers should be converted to use Java 7 String switch instead. The enum values shall be replaced with String constant fields, all enum switches converted to String switches, and all enum types removed from these classes. The net result should be a reduction by dozens if not hundreds of .class files, and possibly a measurable performance boost as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (JGRP-2401) Version number for configuration
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2401?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2401:
---------------------------
Description:
Add a version to the config, which corresponds with the JGroups version.
At startup, if the JGroups version and the config version don't match, issue a warning. Possibly don't start if the major version differs.
Example:
{code:xml}
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"
version="5.0.0.Final">
{code}
was:
Add a version to the config, which corresponds with the JGroups version.
At startup, if the JGroups version and the config version don't match, issue a warning. Possibly don't start if the major version differs.
> Version number for configuration
> --------------------------------
>
> Key: JGRP-2401
> URL: https://issues.redhat.com/browse/JGRP-2401
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> Add a version to the config, which corresponds with the JGroups version.
> At startup, if the JGroups version and the config version don't match, issue a warning. Possibly don't start if the major version differs.
> Example:
> {code:xml}
> <config xmlns="urn:org:jgroups"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"
> version="5.0.0.Final">
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (JGRP-2401) Version number for configuration
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2401?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2401:
---------------------------
Description:
Add a version to the config, which corresponds with the JGroups version.
At startup, if the JGroups version and the config version don't match, issue a warning. Possibly don't start if the major version differs.
was:
Add a version to the config, which corresponds with the JGroups version.
At startup, if the JGroups version and the confi version don't match, issue a warning. Possibly don't start if the major version differs.
> Version number for configuration
> --------------------------------
>
> Key: JGRP-2401
> URL: https://issues.redhat.com/browse/JGRP-2401
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> Add a version to the config, which corresponds with the JGroups version.
> At startup, if the JGroups version and the config version don't match, issue a warning. Possibly don't start if the major version differs.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFCORE-2516) Changes to the logging subsystem are not persisted to the logging.properties in offline CLI
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-2516?page=com.atlassian.jira.plug... ]
James Perkins commented on WFCORE-2516:
---------------------------------------
It could really go either way. One would expect if they boot the embedded CLI server that the changes would be seen on the next boot. However logging is a special case where the model would be updated, but the {{logging.properties}} file would not. So if say they remove the console handler, on the first boot the console handler would still log messages until the logging subsystem kicks in.
> Changes to the logging subsystem are not persisted to the logging.properties in offline CLI
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-2516
> URL: https://issues.redhat.com/browse/WFCORE-2516
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> When using {{embed-server}} within offline CLI changes to the logging subsystem are not persisted to the {{logging.properties}} file.
> Do note that before we fix this we may want to consider a fix for WFCORE-157. The issue being that offline CLI is likely used to provision a server and that server may be configured in a different location. Since the {{jboss.server.log.dir}} or other {{relative-to}} property will be resolved and written as a fully-qualified path this could be an issue.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (DROOLS-4746) UX for DMN "quick test" tool
by Guilherme Gomes (Jira)
[ https://issues.redhat.com/browse/DROOLS-4746?page=com.atlassian.jira.plug... ]
Guilherme Gomes commented on DROOLS-4746:
-----------------------------------------
Hi [~uxdlc],
During our scrum meeting, you mentioned that you would need more examples of boxed expressions outputs.
Let's start checking a Decision Table example (which we're familiar with), and then we can check other boxed expressions.
h3. Decision Tables
Consider this example:
!decision-logic-3-2.png|width=800!
Each row represents a rule, thus when the input matches, the respective output value is selected as the decision output. Considering the decision table above, check the following examples and their expected output:
h5. Example 1
Let's consider this input data:
{code}
"Violation": {
"Type": "speed",
"Speed Limit": 60,
"Actual Speed": 100
}
{code}
When users execute this boxed expression, we can expect this output data:
{code}
"Fine": {
"Points": 7,
"Amount": 1000
}
{code}
h5. Example 2
Let's consider this input data:
{code}
"Violation": {
"Type": "speed",
"Speed Limit": 60,
"Actual Speed": 70
}
{code}
When users execute this boxed expression, we can expect this output data:
{code}
"Fine": {
"Points": 3,
"Amount": 500
}
{code}
h3. Other boxed expressions
All right, now let's check other boxed expressions. See this context boxed expression:
!decision-logic-2-2.png|width=800!
Contexts represent a collection of one or more key-value pairs, where the value is a decision logic, and the key is the respective identifier. The value can contain any type of expression: a literal expression, a decision table, a relation, function, an invocation, or even another context. Generally, contexts hold one or more local variables (values related to a local context).
The example above has only one key-value pair. The key is *"Total"* and the value is this Literal Expression: *Driver points + Violation points*
Considering this example, when *"Driver points"* and *"Violation points"* are, respectively, *10* and *5*, the output node *"Should the driver be suspended?"* returns *"NO"*. However, with *"Driver points"* and *"Violation points"* with *10* and *15*, the output node *"Should the driver be suspended?"* returns *"YES"*.
In the example above, we've checked _Literal Expressions_ and _Contexts_.
I think these three boxed expressions types are the most complex ones. You can check the others [here|http://learn-dmn-in-15-minutes.com/learn/decision-logic], but I don't think it's necessary.
Please, ping me if the examples above are not clear enough :)
> UX for DMN "quick test" tool
> ----------------------------
>
> Key: DROOLS-4746
> URL: https://issues.redhat.com/browse/DROOLS-4746
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: decision-logic-2-2.png, decision-logic-3-2.png
>
>
> As a DMN author, I'd like to probe the DMN model during the authoring phase without leaving the DMN Editor. Actually, it's really important to explore the DMN model to understand with values are required by the test.
> When the user run the test he can get back the results of the DMN execution.
> Moreover, it would be handy to add those input/output to an existing (or new) test scenario.
> *Acceptance criteria*
> Users are able to:
> * Execute a single node boxed expression by providing node inputs (within the DMN editor.)
> * Explore the DMN model and provide inputs necessary to run a scenario test.
> * Obtain results (Expected) within the DMN editor once the test is run.
> Notes:
> * Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output.
> * Out of scope: Saving or exporting the "quick test."
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (DROOLS-4746) UX for DMN "quick test" tool
by Guilherme Gomes (Jira)
[ https://issues.redhat.com/browse/DROOLS-4746?page=com.atlassian.jira.plug... ]
Guilherme Gomes updated DROOLS-4746:
------------------------------------
Attachment: decision-logic-3-2.png
> UX for DMN "quick test" tool
> ----------------------------
>
> Key: DROOLS-4746
> URL: https://issues.redhat.com/browse/DROOLS-4746
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: decision-logic-2-2.png, decision-logic-3-2.png
>
>
> As a DMN author, I'd like to probe the DMN model during the authoring phase without leaving the DMN Editor. Actually, it's really important to explore the DMN model to understand with values are required by the test.
> When the user run the test he can get back the results of the DMN execution.
> Moreover, it would be handy to add those input/output to an existing (or new) test scenario.
> *Acceptance criteria*
> Users are able to:
> * Execute a single node boxed expression by providing node inputs (within the DMN editor.)
> * Explore the DMN model and provide inputs necessary to run a scenario test.
> * Obtain results (Expected) within the DMN editor once the test is run.
> Notes:
> * Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output.
> * Out of scope: Saving or exporting the "quick test."
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (DROOLS-4746) UX for DMN "quick test" tool
by Guilherme Gomes (Jira)
[ https://issues.redhat.com/browse/DROOLS-4746?page=com.atlassian.jira.plug... ]
Guilherme Gomes updated DROOLS-4746:
------------------------------------
Attachment: decision-logic-2-2.png
> UX for DMN "quick test" tool
> ----------------------------
>
> Key: DROOLS-4746
> URL: https://issues.redhat.com/browse/DROOLS-4746
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: decision-logic-2-2.png
>
>
> As a DMN author, I'd like to probe the DMN model during the authoring phase without leaving the DMN Editor. Actually, it's really important to explore the DMN model to understand with values are required by the test.
> When the user run the test he can get back the results of the DMN execution.
> Moreover, it would be handy to add those input/output to an existing (or new) test scenario.
> *Acceptance criteria*
> Users are able to:
> * Execute a single node boxed expression by providing node inputs (within the DMN editor.)
> * Explore the DMN model and provide inputs necessary to run a scenario test.
> * Obtain results (Expected) within the DMN editor once the test is run.
> Notes:
> * Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output.
> * Out of scope: Saving or exporting the "quick test."
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months