[JBoss JIRA] (DROOLS-4161) Scenario Test: UX for DMN Decision service
by Amy Glass (Jira)
[ https://issues.jboss.org/browse/DROOLS-4161?page=com.atlassian.jira.plugi... ]
Amy Glass commented on DROOLS-4161:
-----------------------------------
Ok good that's what I thought [~kkufova] - I think its placement at the bottom just above Save is fine then [~zhutaojiajia]
> Scenario Test: UX for DMN Decision service
> ------------------------------------------
>
> Key: DROOLS-4161
> URL: https://issues.jboss.org/browse/DROOLS-4161
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to test my decision service from a DMN model.
> User needs to specify DMN model and decision service name to be tested.
> Note: a decision service contains only a subset of decisions so the template (header) need to be updated/recreated or the information needs to be available during template creation
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (DROOLS-4161) Scenario Test: UX for DMN Decision service
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-4161?page=com.atlassian.jira.plugi... ]
Klara Kufova edited comment on DROOLS-4161 at 7/19/19 8:34 AM:
---------------------------------------------------------------
[~aglass], if the *skip simulation* box is checked, the tests defined in this particular test scenario asset are not executed when the project is built or when the tests are run on a project level. This means that it doesn't really affect any other values in the *Settings* dock; these values are still saved and used when the asset's tests are executed (for example in the designer itself).
was (Author: kkufova):
[~aglass], if the *skip simulation* box is checked, the tests defined in this particular test scenario asset are not executed when the project is built or when the tests are executed on a project level. This means that it doesn't really affect any other value in the *Settings* dock; they are saved and used when the tests are executed (for example in the designer itself).
> Scenario Test: UX for DMN Decision service
> ------------------------------------------
>
> Key: DROOLS-4161
> URL: https://issues.jboss.org/browse/DROOLS-4161
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to test my decision service from a DMN model.
> User needs to specify DMN model and decision service name to be tested.
> Note: a decision service contains only a subset of decisions so the template (header) need to be updated/recreated or the information needs to be available during template creation
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (DROOLS-4161) Scenario Test: UX for DMN Decision service
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-4161?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-4161:
--------------------------------------
[~aglass], if the *skip simulation* box is checked, the tests defined in this particular test scenario asset are not executed when the project is built or when the tests are executed on a project level. This means that it doesn't really affect any other value in the *Settings* dock; they are saved and used when the tests are executed (for example in the designer itself).
> Scenario Test: UX for DMN Decision service
> ------------------------------------------
>
> Key: DROOLS-4161
> URL: https://issues.jboss.org/browse/DROOLS-4161
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to test my decision service from a DMN model.
> User needs to specify DMN model and decision service name to be tested.
> Note: a decision service contains only a subset of decisions so the template (header) need to be updated/recreated or the information needs to be available during template creation
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (DROOLS-4161) Scenario Test: UX for DMN Decision service
by Amy Glass (Jira)
[ https://issues.jboss.org/browse/DROOLS-4161?page=com.atlassian.jira.plugi... ]
Amy Glass commented on DROOLS-4161:
-----------------------------------
I like it [~zhutaojiajia] Thank you.
I left a question in the Marvel but asking here for [~danielezonca] -- Is the "Skip this simulation during the test" meant as a way for the user to save all the values in Settings but not use them for a test? In other words, does it apply to everything configured in that Settings panel?
> Scenario Test: UX for DMN Decision service
> ------------------------------------------
>
> Key: DROOLS-4161
> URL: https://issues.jboss.org/browse/DROOLS-4161
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to test my decision service from a DMN model.
> User needs to specify DMN model and decision service name to be tested.
> Note: a decision service contains only a subset of decisions so the template (header) need to be updated/recreated or the information needs to be available during template creation
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFLY-12304) Upgrade Apache Artemis from 2.8.1 to 2.9.0
by Martin Stefanko (Jira)
Martin Stefanko created WFLY-12304:
--------------------------------------
Summary: Upgrade Apache Artemis from 2.8.1 to 2.9.0
Key: WFLY-12304
URL: https://issues.jboss.org/browse/WFLY-12304
Project: WildFly
Issue Type: Component Upgrade
Components: JMS
Reporter: Martin Stefanko
Assignee: Emmanuel Hugonnet
Fix For: 17.0.0.Beta1, 17.0.0.Final
Upgrade Apache Artemis from 2.8.0.Final to 2.8.1.Final.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (DROOLS-4161) Scenario Test: UX for DMN Decision service
by Tao Zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-4161?page=com.atlassian.jira.plugi... ]
Tao Zhu commented on DROOLS-4161:
---------------------------------
Thank you. [~aglass]Yeap, I thought of that idea too, but dose not used it later yesterday, because there is one the other checkbox. To separate them feels a little strange.
I have thought more about it today. they are not group choices, so it's not very strange to separate them. Here is a new update. https://marvelapp.com/c3h94ah Please review again.
> Scenario Test: UX for DMN Decision service
> ------------------------------------------
>
> Key: DROOLS-4161
> URL: https://issues.jboss.org/browse/DROOLS-4161
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to test my decision service from a DMN model.
> User needs to specify DMN model and decision service name to be tested.
> Note: a decision service contains only a subset of decisions so the template (header) need to be updated/recreated or the information needs to be available during template creation
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11833 at 7/19/19 6:43 AM:
---------------------------------------------------------------------
I'm attaching a detailed log of test execution with just about everything written out: test-debug-log.txt
One thing I discovered was that affinities are being processed even in the marshaling code (see ProtocolV3ObjectResolver). When a proxy is marshaled, certain affinities are substituted with other affinities using the class ProtocolV3ObjectResolver, depending on the endpoints of the connection handing the invocation. This is where the unexpected URI affinities are coming from in this example. The ObjectResolver keeps track, for the current connection, of the sender's NodeAffinity and URIAffinity, as well as the receiver's NodeAffinity and URIAffinity and uses these values in substitution of what goes into the stream and what comes out of the stream.
At present, the code in ProtocolV3ObjectResolver works like this:
* when writing ("replacing") an Affinity object into the stream:
** if the object corresponds to Affinity.LOCAL (and the sender's NodeAffinity exists) , replace Affinity.LOCAL with the sender's NodeAffinity
** if the object corresponds to the receiver's URIAffinity, replace the receiver's URIAffinity with the receiver's NodeAffinity
* when reading ("resolving") an affinity object from the stream:
** if the object corresponds to Affinity.LOCAL, resolve this to the sender's URIAffinity (if we prefer URIs), or the sender's NodeAffinity (if it exists) or NONE
** if the object corresponds to the receiver's NodeAffinity, resolve this to Affinity.LOCAL, else if the object corresponds to the sender's NodeAffinity, resolve to the sender's URIAffinity
What we are seeing in this issue is the case where:
* when writing, Affinity.LOCAL is being replaced by the sender's NodeAffinity
* when reading, the sender's NodeAffinity is replaced by the sender's URIAffinity
Re-iterating the original problems in this issue, a proxy for a remote view of a bean is created on a server (which is also a member of a cluster) and is shipped across the network (maybe via multiple servers) back to a client. The proxy is created with Affinity.LOCAL and is getting translated into other values when shipped across the network, based on connection endpoints. If this is the way the scheme was intended to function, i'm not sure it is a workable solution.
was (Author: rachmato):
I'm attaching a detailed log of test execution with just about everything written out: test-debug-log.txt
One thing I discovered was that affinities are being processed even in the marshaling code (see ProtocolV3ObjectResolver). When a proxy is marshaled, certain affinities are substituted with other affinities using the class ProtocolV3ObjectResolver, depending on the endpoints of the connection handing the invocation. This is where the unexpected URI affinities are coming from in this example. The ObjectResolver keeps track, for the current connection, of the sender's NodeAffinity and URIAffinity, as well as the receiver's NodeAffinity and URIAffinity and uses these values in substitution of what goes into the stream and what comes out of the stream.
At present, the code in ProtocolV3ObjectResolver works like this:
* when writing ("replacing") an Affinity object into the stream:
** if the object corresponds to Affinity.LOCAL (and the sender's NodeAffinity exists) , replace Affinity.LOCAL with the sender's NodeAffinity
** if the object corresponds to the receiver's URIAffinity, replace the receiver's URIAffinity with the receiver's NodeAffinity
* when reading ("resolving") an affinity object from the stream:
** if the object corresponds to Affinity.LOCAL, resolve this to the sender's URIAffinity (if we prefer URIs), or the sender's NodeAffinity (if it exists) or NONE
** if the object corresponds to the receiver's NodeAffinity, resolve this to Affinity.LOCAL, else if the object corresponds to the sender's NodeAffinity, resolve to the sender's URIAffinity
What we are seeing in this issue is the case where:
* when writing, Affinity.LOCAL is being replaced by the sender's NodeAffinity
* when reading, the sender's NodeAffinity is replaced by the sender's URIAffinity
> Stateful Session Bean affinity URI instead of cluster
> -----------------------------------------------------
>
> Key: WFLY-11833
> URL: https://issues.jboss.org/browse/WFLY-11833
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 16.0.0.Final
> Environment: WildFly cluster having SFSB deployed.
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: stateful-timeout.zip, test-debug-log.txt
>
>
> Deployed is an application with the following setup:
> * Containing a SFSB (_with passivationCapable="true"_)
> * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB
> Scenario:
> A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned.
> The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster.
> See the attached Gradle reproducer application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years