[JBoss JIRA] (DROOLS-2890) [DMN Designer] DMNDiagram properties
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-2890?page=com.atlassian.jira.plugi... ]
Michael Anstis edited comment on DROOLS-2890 at 11/2/18 5:56 AM:
-----------------------------------------------------------------
[~jomarko] I repeated your tests with a 1.1 file and it worked correctly too.
was (Author: manstis):
@jomarko I repeated your tests with a 1.1 file and it worked correctly too.
> [DMN Designer] DMNDiagram properties
> ------------------------------------
>
> Key: DROOLS-2890
> URL: https://issues.jboss.org/browse/DROOLS-2890
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.10.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Fix For: 7.10.0.Final
>
>
> The {{DMNDiagram}} node needs to expose the following properties (from [~tirelli] on DROOLS-[2870|https://issues.jboss.org/browse/DROOLS-2870?focusedCommentId...)
> {quote}
> The Definitions properties that I think we need to expose are:
> * Id (probably read only)
> * name (needs to be editable; can default to the file name but should remain editable)
> * namespace
> * Also, the "description" element should probably be exposed somehow, although with lower priority. If you want just the minimal set, then the above.
> {quote}
> h2. Manual acceptance test
> h3. 1.1 file
> - Import model with namespace (/)
> - Import model without namespace (/)
> h3. 1.2 file
> - B&D new model, non default namespace (/)
> - Import model with namespace (/)
> - Import model without namespace (/)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-2890) [DMN Designer] DMNDiagram properties
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-2890?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2890:
----------------------------------------
@jomarko I repeated your tests with a 1.1 file and it worked correctly too.
> [DMN Designer] DMNDiagram properties
> ------------------------------------
>
> Key: DROOLS-2890
> URL: https://issues.jboss.org/browse/DROOLS-2890
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.10.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Fix For: 7.10.0.Final
>
>
> The {{DMNDiagram}} node needs to expose the following properties (from [~tirelli] on DROOLS-[2870|https://issues.jboss.org/browse/DROOLS-2870?focusedCommentId...)
> {quote}
> The Definitions properties that I think we need to expose are:
> * Id (probably read only)
> * name (needs to be editable; can default to the file name but should remain editable)
> * namespace
> * Also, the "description" element should probably be exposed somehow, although with lower priority. If you want just the minimal set, then the above.
> {quote}
> h2. Manual acceptance test
> - B&D new model, non default namespace (/)
> - Import model with namespace (/)
> - Import model without namespace (/)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-2890) [DMN Designer] DMNDiagram properties
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-2890?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2890:
-----------------------------------
Description:
The {{DMNDiagram}} node needs to expose the following properties (from [~tirelli] on DROOLS-[2870|https://issues.jboss.org/browse/DROOLS-2870?focusedCommentId...)
{quote}
The Definitions properties that I think we need to expose are:
* Id (probably read only)
* name (needs to be editable; can default to the file name but should remain editable)
* namespace
* Also, the "description" element should probably be exposed somehow, although with lower priority. If you want just the minimal set, then the above.
{quote}
h2. Manual acceptance test
h3. 1.1 file
- Import model with namespace (/)
- Import model without namespace (/)
h3. 1.2 file
- B&D new model, non default namespace (/)
- Import model with namespace (/)
- Import model without namespace (/)
was:
The {{DMNDiagram}} node needs to expose the following properties (from [~tirelli] on DROOLS-[2870|https://issues.jboss.org/browse/DROOLS-2870?focusedCommentId...)
{quote}
The Definitions properties that I think we need to expose are:
* Id (probably read only)
* name (needs to be editable; can default to the file name but should remain editable)
* namespace
* Also, the "description" element should probably be exposed somehow, although with lower priority. If you want just the minimal set, then the above.
{quote}
h2. Manual acceptance test
- B&D new model, non default namespace (/)
- Import model with namespace (/)
- Import model without namespace (/)
> [DMN Designer] DMNDiagram properties
> ------------------------------------
>
> Key: DROOLS-2890
> URL: https://issues.jboss.org/browse/DROOLS-2890
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.10.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Fix For: 7.10.0.Final
>
>
> The {{DMNDiagram}} node needs to expose the following properties (from [~tirelli] on DROOLS-[2870|https://issues.jboss.org/browse/DROOLS-2870?focusedCommentId...)
> {quote}
> The Definitions properties that I think we need to expose are:
> * Id (probably read only)
> * name (needs to be editable; can default to the file name but should remain editable)
> * namespace
> * Also, the "description" element should probably be exposed somehow, although with lower priority. If you want just the minimal set, then the above.
> {quote}
> h2. Manual acceptance test
> h3. 1.1 file
> - Import model with namespace (/)
> - Import model without namespace (/)
> h3. 1.2 file
> - B&D new model, non default namespace (/)
> - Import model with namespace (/)
> - Import model without namespace (/)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3226) [DMN Designer] Function Header Cell in BKM
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3226?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3226:
--------------------------------
Description:
Function header cell can be selected, but user can't set its properties in PropertiesPanel if the Function is the top level Expression of the BKM node. See below comparision of Function as the top level Expression. Once in decision node, then in BKM node.
h3. Decision node
!Screenshot from 2018-11-01 13-25-03.png|thumbnail!
h3. BKM node
!Screenshot from 2018-11-01 13-25-21.png|thumbnail!
h2. Manual Acceptance test
- Select Expression Header cell of BKM node
- Change Properties via properties panel
- Try to clear BKM node definition, shouldn't be possible
- Build and Deploy
- Runtime
was:
Function header cell can be selected, but user can't set its properties in PropertiesPanel if the Function is the top level Expression of the BKM node. See below comparision of Function as the top level Expression. Once in decision node, then in BKM node.
h3. Decision node
!Screenshot from 2018-11-01 13-25-03.png|thumbnail!
h3. BKM node
!Screenshot from 2018-11-01 13-25-21.png|thumbnail!
> [DMN Designer] Function Header Cell in BKM
> ------------------------------------------
>
> Key: DROOLS-3226
> URL: https://issues.jboss.org/browse/DROOLS-3226
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2018-11-01 13-25-03.png, Screenshot from 2018-11-01 13-25-21.png
>
>
> Function header cell can be selected, but user can't set its properties in PropertiesPanel if the Function is the top level Expression of the BKM node. See below comparision of Function as the top level Expression. Once in decision node, then in BKM node.
> h3. Decision node
> !Screenshot from 2018-11-01 13-25-03.png|thumbnail!
> h3. BKM node
> !Screenshot from 2018-11-01 13-25-21.png|thumbnail!
> h2. Manual Acceptance test
> - Select Expression Header cell of BKM node
> - Change Properties via properties panel
> - Try to clear BKM node definition, shouldn't be possible
> - Build and Deploy
> - Runtime
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11272) wildfly-microprofile-health-smallrye_1_0.xsd doesn't have documentation for allowed attributes
by Rostislav Svoboda (Jira)
Rostislav Svoboda created WFLY-11272:
----------------------------------------
Summary: wildfly-microprofile-health-smallrye_1_0.xsd doesn't have documentation for allowed attributes
Key: WFLY-11272
URL: https://issues.jboss.org/browse/WFLY-11272
Project: WildFly
Issue Type: Bug
Components: MP Health
Reporter: Rostislav Svoboda
Assignee: Jeff Mesnil
wildfly-microprofile-health-smallrye_1_0.xsd doesn't have documentation for allowed attributes
CLI provides description via {{/subsystem=microprofile-health-smallrye:read-resource-description()}}.
Same information should be present in wildfly-microprofile-health-smallrye_1_0.xsd via <xs:annotation> and <xs:documentation>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11273) wildfly-microprofile-config-smallrye_1_0.xsd doesn't have documentation for allowed elements and attributes
by Rostislav Svoboda (Jira)
Rostislav Svoboda created WFLY-11273:
----------------------------------------
Summary: wildfly-microprofile-config-smallrye_1_0.xsd doesn't have documentation for allowed elements and attributes
Key: WFLY-11273
URL: https://issues.jboss.org/browse/WFLY-11273
Project: WildFly
Issue Type: Bug
Components: MP Config
Reporter: Rostislav Svoboda
Assignee: Jeff Mesnil
wildfly-microprofile-config-smallrye_1_0.xsd doesn't have documentation for allowed elements and attributes
CLI provides description via {{/subsystem=microprofile-config-smallrye:read-resource-description(recursive)}}.
Same information should be present in wildfly-microprofile-config-smallrye_1_0.xsd via <xs:annotation> and <xs:documentation>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFWIP-133) wildfly-microprofile-metrics-smallrye_1_0.xsd should provide some documentation for allowed attributes
by Rostislav Svoboda (Jira)
[ https://issues.jboss.org/browse/WFWIP-133?page=com.atlassian.jira.plugin.... ]
Rostislav Svoboda commented on WFWIP-133:
-----------------------------------------
{{<!-- The subsystem root element -->}} comment could be probably removed from xsd
> wildfly-microprofile-metrics-smallrye_1_0.xsd should provide some documentation for allowed attributes
> ------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-133
> URL: https://issues.jboss.org/browse/WFWIP-133
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Metrics
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Major
>
> wildfly-microprofile-metrics-smallrye_1_0.xsd should provide some documentation for allowed attributes
> CLI provides description for attributes via {{/subsystem=microprofile-metrics-smallrye:read-resource-description}}.
> Same information should be present in wildfly-microprofile-metrics-smallrye_1_0.xsd via {{<xs:annotation>}} and {{<xs:documentation>}}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3228) Rules don't produce the correct result anymore after a session reset
by Christian Liebhardt (Jira)
[ https://issues.jboss.org/browse/DROOLS-3228?page=com.atlassian.jira.plugi... ]
Christian Liebhardt updated DROOLS-3228:
----------------------------------------
Description:
Hello,
A while ago I've created a test project to compare the different possibilities of session types and session polling/reusing. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
*1. Incorrect results*
If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
index 020446190c..48045697af 100644
---
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
+++
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
@@ -16,6 +16,8 @@
package org.drools.core.common;
+import java.util.HashSet;
+import java.util.Set;
import java.util.concurrent.atomic.AtomicReferenceArray;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
public void resetAllMemories(StatefulKnowledgeSession session) {
InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
+ Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
for (int i = 0; i < memories.length(); i++) {
Memory memory = memories.get(i);
if (memory != null) {
if (memory.getSegmentMemory() != null) {
- SegmentMemory smem = memory.getSegmentMemory();
- smem.reset(kBase.getSegmentPrototype(smem));
- if ( smem.isSegmentLinked() ) {
- smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
- }
+ smems.add(memory.getSegmentMemory());
}
memory.reset();
}
}
+
+ for (SegmentMemory smem : smems) {
+ smem.reset(kBase.getSegmentPrototype(smem));
+ if ( smem.isSegmentLinked() ) {
+ smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
+ }
+ }
}
/**
{code}
I tried to find out why the order matters here, but apparently lack knowledge.
*2. Reset doesn't bring a disposed session back to life*
With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
index d6f4959e0d..4a6199ad23 100644
---
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
+++
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
@@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
AbstractRuntime
this.processRuntime = null;
this.initialFactHandle = initInitialFact(kBase, null);
+
+ this.alive = true;
}
public void reset(int handleId,
{code}
was:
Hello,
A while ago I've created a test projects to compare the different possibilities of session types and session polling/reusing. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
*1. Incorrect results*
If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
index 020446190c..48045697af 100644
---
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
+++
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
@@ -16,6 +16,8 @@
package org.drools.core.common;
+import java.util.HashSet;
+import java.util.Set;
import java.util.concurrent.atomic.AtomicReferenceArray;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
public void resetAllMemories(StatefulKnowledgeSession session) {
InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
+ Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
for (int i = 0; i < memories.length(); i++) {
Memory memory = memories.get(i);
if (memory != null) {
if (memory.getSegmentMemory() != null) {
- SegmentMemory smem = memory.getSegmentMemory();
- smem.reset(kBase.getSegmentPrototype(smem));
- if ( smem.isSegmentLinked() ) {
- smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
- }
+ smems.add(memory.getSegmentMemory());
}
memory.reset();
}
}
+
+ for (SegmentMemory smem : smems) {
+ smem.reset(kBase.getSegmentPrototype(smem));
+ if ( smem.isSegmentLinked() ) {
+ smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
+ }
+ }
}
/**
{code}
I tried to find out why the order matters here, but apparently lack knowledge.
*2. Reset doesn't bring a disposed session back to life*
With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
index d6f4959e0d..4a6199ad23 100644
---
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
+++
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
@@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
AbstractRuntime
this.processRuntime = null;
this.initialFactHandle = initInitialFact(kBase, null);
+
+ this.alive = true;
}
public void reset(int handleId,
{code}
> Rules don't produce the correct result anymore after a session reset
> --------------------------------------------------------------------
>
> Key: DROOLS-3228
> URL: https://issues.jboss.org/browse/DROOLS-3228
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.13.0.Final
> Reporter: Christian Liebhardt
> Assignee: Mario Fusco
> Priority: Major
>
> Hello,
> A while ago I've created a test project to compare the different possibilities of session types and session polling/reusing. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
> *1. Incorrect results*
> If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
> {code:java}
> diff --git
> a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> index 020446190c..48045697af 100644
> ---
> a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> +++
> b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> @@ -16,6 +16,8 @@
> package org.drools.core.common;
> +import java.util.HashSet;
> +import java.util.Set;
> import java.util.concurrent.atomic.AtomicReferenceArray;
> import java.util.concurrent.locks.Lock;
> import java.util.concurrent.locks.ReentrantLock;
> @@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
> public void resetAllMemories(StatefulKnowledgeSession session) {
> InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
> + Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
> for (int i = 0; i < memories.length(); i++) {
> Memory memory = memories.get(i);
> if (memory != null) {
> if (memory.getSegmentMemory() != null) {
> - SegmentMemory smem = memory.getSegmentMemory();
> - smem.reset(kBase.getSegmentPrototype(smem));
> - if ( smem.isSegmentLinked() ) {
> - smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
> - }
> + smems.add(memory.getSegmentMemory());
> }
> memory.reset();
> }
> }
> +
> + for (SegmentMemory smem : smems) {
> + smem.reset(kBase.getSegmentPrototype(smem));
> + if ( smem.isSegmentLinked() ) {
> + smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
> + }
> + }
> }
> /**
> {code}
> I tried to find out why the order matters here, but apparently lack knowledge.
> *2. Reset doesn't bring a disposed session back to life*
> With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
> The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
> {code:java}
> diff --git
> a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> index d6f4959e0d..4a6199ad23 100644
> ---
> a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> +++
> b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> @@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
> AbstractRuntime
> this.processRuntime = null;
> this.initialFactHandle = initInitialFact(kBase, null);
> +
> + this.alive = true;
> }
> public void reset(int handleId,
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months