[JBoss JIRA] (JGRP-2239) AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE)
by Boris Sh (JIRA)
[ https://issues.jboss.org/browse/JGRP-2239?page=com.atlassian.jira.plugin.... ]
Boris Sh updated JGRP-2239:
---------------------------
Description:
Hello,
I am using the following configuration:
{code:java}
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
<UDP />
<PING />
<MERGE3 />
<FD />
<VERIFY_SUSPECT />
<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
asym_algorithm="RSA" />
<pbcast.NAKACK2 />
<UNICAST3 />
<pbcast.STABLE />
<FRAG2 />
<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
cipher_type="RSA" />
<pbcast.GMS />
</config>
{code}
I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.
Initially, when these nodes join the cluster, everything is fine.
The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):
{code:java}
org.jgroups.protocols.FD up
WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-36734
org.jgroups.protocols.Encrypt handleEncryptedMessage
{code}
so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".
In cluster coordinator logs I see the following:
{code:java}
INFO: ISPN100000: Node node-26978 joined the cluster
****
WARN: node-27291: unrecognized cipher; discarding message from node-26978
org.jgroups.logging.Slf4jLogImpl error
ERROR: key requester node-26978 is not in current view [***]; ignoring key request
org.jgroups.logging.Slf4jLogImpl warn
WARN: node-27291: unrecognized cipher; discarding message from node-26978
INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]
{code}
My understanding of what has happened:
For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and I don't fully understand why this happens.
How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, and the key doesn't change.
Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.
So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.
was:
Hello,
I am using the following configuration:
{code:java}
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
<UDP />
<PING />
<MERGE3 />
<FD />
<VERIFY_SUSPECT />
<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
asym_algorithm="RSA" />
<pbcast.NAKACK2 />
<UNICAST3 />
<pbcast.STABLE />
<FRAG2 />
<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
cipher_type="RSA" />
<pbcast.GMS />
</config>
{code}
I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.
Initially, when these nodes join the cluster, everything is fine.
The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):
{code:java}
org.jgroups.protocols.FD up
WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-36734
org.jgroups.protocols.Encrypt handleEncryptedMessage
{code}
so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".
In cluster coordinator logs I see the following:
{code:java}
INFO: ISPN100000: Node node-26978 joined the cluster
****
WARN: node-27291: unrecognized cipher; discarding message from node-26978
org.jgroups.logging.Slf4jLogImpl error
ERROR: key requester node-26978 is not in current view [***]; ignoring key request
org.jgroups.logging.Slf4jLogImpl warn
WARN: node-27291: unrecognized cipher; discarding message from node-26978
INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]
{code}
My understanding of what has happened:
For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and don't fully understand why this happens.
How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, and the key doesn't change.
Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.
So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.
> AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE)
> ------------------------------------------------------------------
>
> Key: JGRP-2239
> URL: https://issues.jboss.org/browse/JGRP-2239
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Environment: Infinispan 9.1.1 + JGroups 4.0.6.Final + Vert.x 3.5.0
> Reporter: Boris Sh
> Assignee: Bela Ban
>
> Hello,
> I am using the following configuration:
> {code:java}
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> <UDP />
> <PING />
> <MERGE3 />
> <FD />
> <VERIFY_SUSPECT />
> <ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
> sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
> asym_algorithm="RSA" />
> <pbcast.NAKACK2 />
> <UNICAST3 />
> <pbcast.STABLE />
> <FRAG2 />
> <AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
> keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
> cipher_type="RSA" />
> <pbcast.GMS />
> </config>
> {code}
> I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.
> Initially, when these nodes join the cluster, everything is fine.
> The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):
> {code:java}
> org.jgroups.protocols.FD up
> WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-36734
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> {code}
> so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".
> In cluster coordinator logs I see the following:
> {code:java}
> INFO: ISPN100000: Node node-26978 joined the cluster
> ****
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> org.jgroups.logging.Slf4jLogImpl error
> ERROR: key requester node-26978 is not in current view [***]; ignoring key request
> org.jgroups.logging.Slf4jLogImpl warn
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]
> {code}
> My understanding of what has happened:
> For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and I don't fully understand why this happens.
> How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, and the key doesn't change.
> Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.
> So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2239) AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE)
by Boris Sh (JIRA)
Boris Sh created JGRP-2239:
------------------------------
Summary: AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE)
Key: JGRP-2239
URL: https://issues.jboss.org/browse/JGRP-2239
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.6
Environment: Infinispan 9.1.1 + JGroups 4.0.6.Final + Vert.x 3.5.0
Reporter: Boris Sh
Assignee: Bela Ban
Hello,
I am using the following configuration:
{code:java}
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
<UDP />
<PING />
<MERGE3 />
<FD />
<VERIFY_SUSPECT />
<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
asym_algorithm="RSA" />
<pbcast.NAKACK2 />
<UNICAST3 />
<pbcast.STABLE />
<FRAG2 />
<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
cipher_type="RSA" />
<pbcast.GMS />
</config>
{code}
I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.
Initially, when these nodes join the cluster, everything is fine.
The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):
{code:java}
org.jgroups.protocols.FD up
WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-36734
org.jgroups.protocols.Encrypt handleEncryptedMessage
{code}
so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".
In cluster coordinator logs I see the following:
{code:java}
INFO: ISPN100000: Node node-26978 joined the cluster
****
WARN: node-27291: unrecognized cipher; discarding message from node-26978
org.jgroups.logging.Slf4jLogImpl error
ERROR: key requester node-26978 is not in current view [***]; ignoring key request
org.jgroups.logging.Slf4jLogImpl warn
WARN: node-27291: unrecognized cipher; discarding message from node-26978
INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]
{code}
My understanding of what has happened:
For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and don't fully understand why this happens.
How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, and the key doesn't change.
Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.
So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-283 at 12/3/17 2:35 PM:
---------------------------------------------------------
Few notes:
* property *sun.security.jgss.native* needs to be set using JAVA_OPTS="-D ..." before standalone.sh (setting in standalone.xml is applied to late and is ignored by JVM)
* to debug SunNativeProvider add property: *sun.security.nativegss.debug=true*
* currently Elytron initialize LoginContext/Krb5LoginModule even if native provider should be used - should be made optional for future, but for now there is need to provide keystore with given credential to continue (obtained credential should be ignored by GSSManager if correctly set)
* To start: {code}GSSPROXY_BEHAVIOR=REMOTE_FIRST GSS_USE_PROXY=1 JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.jgss.lib=/usr/lib64/libgssapi_krb5.so.2.2 -Dsun.security.jgss.native=true -Dsun.security.nativegss.debug=true -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true" bin/standalone.sh{code}
was (Author: honza889):
Few notes:
* property *sun.security.jgss.native* needs to be set using JAVA_OPTS="-D ..." before standalone.sh (setting in standalone.xml is applied to late and is ignored by JVM)
* to debug SunNativeProvider add property: *sun.security.nativegss.debug=true*
* To start: {code}GSSPROXY_BEHAVIOR=REMOTE_FIRST GSS_USE_PROXY=1 JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.jgss.lib=/usr/lib64/libgssapi_krb5.so.2.2 -Dsun.security.jgss.native=true -Dsun.security.nativegss.debug=true -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true" bin/standalone.sh{code}
> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
> Key: ELY-283
> URL: https://issues.jboss.org/browse/ELY-283
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Peter Skopek
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-283 at 12/3/17 2:20 PM:
---------------------------------------------------------
Few notes:
* property *sun.security.jgss.native* needs to be set using JAVA_OPTS="-D ..." before standalone.sh (setting in standalone.xml is applied to late and is ignored by JVM)
* to debug SunNativeProvider add property: *sun.security.nativegss.debug=true*
* To start: {code}GSSPROXY_BEHAVIOR=REMOTE_FIRST GSS_USE_PROXY=1 JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.jgss.lib=/usr/lib64/libgssapi_krb5.so.2.2 -Dsun.security.jgss.native=true -Dsun.security.nativegss.debug=true -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true" bin/standalone.sh{code}
was (Author: honza889):
Few notes:
* property *sun.security.jgss.native* needs to be set using JAVA_OPTS="-D ..." before standalone.sh (setting in standalone.xml is applied to late and is ignored by JVM)
* to debug SunNativeProvider add property: *sun.security.nativegss.debug=true*
> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
> Key: ELY-283
> URL: https://issues.jboss.org/browse/ELY-283
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Peter Skopek
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-1658) EJBAccessException for methods with @PermitAll but using arrays in parameters
by Marcus Handte (JIRA)
[ https://issues.jboss.org/browse/WFLY-1658?page=com.atlassian.jira.plugin.... ]
Marcus Handte commented on WFLY-1658:
-------------------------------------
Unfortunately, I have to report that this bug seems to be present again in Wildfly-10.1.0.Final.
After replacing an array parameter with a list of the same type on a session bean, I am able to use a method that did not work previously in an arquillian test.
> EJBAccessException for methods with @PermitAll but using arrays in parameters
> -----------------------------------------------------------------------------
>
> Key: WFLY-1658
> URL: https://issues.jboss.org/browse/WFLY-1658
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Alpha2
> Environment: 8.0.0.Alpha2 / Oracle JDK 7
> Reporter: Christophe Fillot
> Assignee: jaikiran pai
> Labels: ejb, security-domain
> Fix For: 8.0.0.Alpha3
>
>
> Calling an EJB method containing an array in parameters throws EJBAccessException, even if the method has @PermitAll annotation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2161) Recursive function definitions in context entries are raising compile time errors
by Edson Tirelli (JIRA)
Edson Tirelli created DROOLS-2161:
-------------------------------------
Summary: Recursive function definitions in context entries are raising compile time errors
Key: DROOLS-2161
URL: https://issues.jboss.org/browse/DROOLS-2161
Project: Drools
Issue Type: Bug
Components: dmn engine
Affects Versions: 7.4.1.Final
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Attachments: ContextRecursion.dmn
Recursive function definitions in contexts are raising compile time errors but are executing correctly.
See attached model for example. Functions "f" and "h" raise compile time errors.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-1597) Implement profile for integration with Signavio's DMN modeler
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1597?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1597:
----------------------------------
Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46 (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48)
> Implement profile for integration with Signavio's DMN modeler
> -------------------------------------------------------------
>
> Key: DROOLS-1597
> URL: https://issues.jboss.org/browse/DROOLS-1597
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Affects Versions: 7.1.0.Beta2
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Fix For: 7.5.0.Final
>
>
> Signavio implements a number of extensions to the DMN standard. As they are a Red Hat partner, we will need to implement a profile in the runtime engine that enables and supports those extensions.
> A short list of extensions is as follows. Details will be added to individual tickets:
> * Support additional FEEL functions and alternate names for existing functions
> * Support the Multi Instance Decision node
> * Support character '?' for interpolation of values in a DT cell
> * Support constraints on List inputs in DT cells
> * Support model composition through BKMs
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2160) Enhance UI in Test Scenarios Editor
by Ivo Bek (JIRA)
Ivo Bek created DROOLS-2160:
-------------------------------
Summary: Enhance UI in Test Scenarios Editor
Key: DROOLS-2160
URL: https://issues.jboss.org/browse/DROOLS-2160
Project: Drools
Issue Type: Enhancement
Components: Test Scenarios Editor
Reporter: Ivo Bek
Assignee: Toni Rikkola
Attachments: Screenshot from 2017-12-01 16-38-52.png
Test Scenarios editor needs to be polished:
* Delete Buttons are too small - it would be good to enlarge them.
* Some other elements doesn't have enough space around them.
* Please do any other small visual changes which makes sense.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years