January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2269) Retrieve all rules associated to a ruleflow-group

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2269?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-2269: ------------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Retrieve all rules associated to a ruleflow-group > ------------------------------------------------- > > Key: DROOLS-2269 > URL: https://issues.jboss.org/browse/DROOLS-2269 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.5.0.Final > Reporter: Richard Bourner > Assignee: Mario Fusco > Priority: Minor > > It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask. > Maybe another way to do it would be via a search using metadata (such as ruleflow-group). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2269) Retrieve all rules associated to a ruleflow-group

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2269?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-2269: ---------------------------------- Affects Version/s: 7.5.0.Final > Retrieve all rules associated to a ruleflow-group > ------------------------------------------------- > > Key: DROOLS-2269 > URL: https://issues.jboss.org/browse/DROOLS-2269 > Project: Drools > Issue Type: Enhancement > Affects Versions: 7.5.0.Final > Reporter: Richard Bourner > Assignee: Edson Tirelli > Priority: Minor > > It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask. > Maybe another way to do it would be via a search using metadata (such as ruleflow-group). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2270) [DMN Editor] Replace "Return to DRG" button with Link

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2270?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2270: -------------------------------- QE Status: ON_QA (was: NEW) > [DMN Editor] Replace "Return to DRG" button with Link > ----------------------------------------------------- > > Key: DROOLS-2270 > URL: https://issues.jboss.org/browse/DROOLS-2270 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Affects Versions: 7.5.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > > The "Return to DRG" button should be replaced with a "<< Back to XXX" link. > XXX should be the name of the DRG from whence the User came. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old members doesn't seem to get removed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2232 at 1/24/18 7:53 AM: --------------------------------------------------------- Try reducing {{logical_addr_cache_max_size}} (default: 2000). E.g. set it to 10 or 20. was (Author: belaban): Try reducing {{logical_addr_cache_max_size}} (default: 2000). E.g. set it to 10 0r 20. > Using NATIVE_S3_PING old members doesn't seem to get removed > ------------------------------------------------------------ > > Key: JGRP-2232 > URL: https://issues.jboss.org/browse/JGRP-2232 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.7 > Environment: Spring Boot / Boxfuse / AWS > Reporter: Jesper Blomquist > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.10 > > > According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us. > Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!). > Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age): > 967 elements: > {noformat} > i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old) > i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old) > i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old) > i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old) > i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old) > i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old) > i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old) > i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old) > i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old) > i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old) > i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old) > i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old) > ... > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old members doesn't seem to get removed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2232: -------------------------------- OK, I can reproduce this even with {{FILE_PING}}, working on it... > Using NATIVE_S3_PING old members doesn't seem to get removed > ------------------------------------------------------------ > > Key: JGRP-2232 > URL: https://issues.jboss.org/browse/JGRP-2232 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.7 > Environment: Spring Boot / Boxfuse / AWS > Reporter: Jesper Blomquist > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.10 > > > According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us. > Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!). > Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age): > 967 elements: > {noformat} > i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old) > i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old) > i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old) > i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old) > i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old) > i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old) > i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old) > i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old) > i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old) > i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old) > i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old) > i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old) > ... > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3541) Missing password types set-password operation of modifiable realms

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3541?page=com.atlassian.jira.plugi... ] Jan Kalina updated WFCORE-3541: ------------------------------- Labels: elytron (was: ) > Missing password types set-password operation of modifiable realms > ------------------------------------------------------------------ > > Key: WFCORE-3541 > URL: https://issues.jboss.org/browse/WFCORE-3541 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 4.0.0.Alpha6 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: elytron > > Not all password types are covered by *set-password* operation in ModifiableRealmDecorator. > At least *ScramDigestPassword* is not available. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3541) Missing password types in set-password operation of modifiable realms

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3541?page=com.atlassian.jira.plugi... ] Jan Kalina updated WFCORE-3541: ------------------------------- Summary: Missing password types in set-password operation of modifiable realms (was: Missing password types set-password operation of modifiable realms) > Missing password types in set-password operation of modifiable realms > --------------------------------------------------------------------- > > Key: WFCORE-3541 > URL: https://issues.jboss.org/browse/WFCORE-3541 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 4.0.0.Alpha6 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: elytron > > Not all password types are covered by *set-password* operation in ModifiableRealmDecorator. > At least *ScramDigestPassword* is not available. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3541) Missing password types set-password operation of modifiable realms

by Jan Kalina (JIRA)

Jan Kalina created WFCORE-3541: ---------------------------------- Summary: Missing password types set-password operation of modifiable realms Key: WFCORE-3541 URL: https://issues.jboss.org/browse/WFCORE-3541 Project: WildFly Core Issue Type: Bug Components: Security Affects Versions: 4.0.0.Alpha6 Reporter: Jan Kalina Assignee: Jan Kalina Priority: Critical Not all password types are covered by *set-password* operation in ModifiableRealmDecorator. At least *ScramDigestPassword* is not available. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3075) KeyStore password as default KeyManager password

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3075?page=com.atlassian.jira.plugi... ] Jan Kalina updated WFCORE-3075: ------------------------------- Issue Type: Enhancement (was: Bug) > KeyStore password as default KeyManager password > ------------------------------------------------ > > Key: WFCORE-3075 > URL: https://issues.jboss.org/browse/WFCORE-3075 > Project: WildFly Core > Issue Type: Enhancement > Components: Security > Reporter: Jan Kalina > Priority: Critical > Labels: keymanager, keystore, trustmanager > > In Elytron, there is keystore password (key-store resource) and key password (key-managers resource) required. > However in theory there could be cases, where no password can be intended > - key-store resource for truststore purposes (reading truststore) (but in legacy is password required) > - PKCS12 can be created without key password (but keystore password in legacy is required) > - you can create JKS programatically without keystore password > - *in legacy key password is optional (which mean keystore password is used)* > From discussion: We can make the password optional on the KeyManager so if no password is specified on the KeyManager we assume it is the one from the KeyStore. > Created analysis document for this: https://developer.jboss.org/wiki/AnalysisDesign-KeyStorePasswordAsDefault... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old members doesn't seem to get removed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2232 at 1/24/18 7:29 AM: --------------------------------------------------------- Try reducing {{logical_addr_cache_max_size}} (default: 2000). E.g. set it to 10 0r 20. was (Author: belaban): Try reducing {{logical_addr_cache_max_size}} (default: 2000). > Using NATIVE_S3_PING old members doesn't seem to get removed > ------------------------------------------------------------ > > Key: JGRP-2232 > URL: https://issues.jboss.org/browse/JGRP-2232 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.7 > Environment: Spring Boot / Boxfuse / AWS > Reporter: Jesper Blomquist > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.10 > > > According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us. > Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!). > Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age): > 967 elements: > {noformat} > i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old) > i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old) > i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old) > i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old) > i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old) > i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old) > i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old) > i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old) > i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old) > i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old) > i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old) > i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old) > ... > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2018