September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4559) DMN additional FEEL temporal functions

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-4559: -------------------------------------- Summary: DMN additional FEEL temporal functions Key: DROOLS-4559 URL: https://issues.jboss.org/browse/DROOLS-4559 Project: Drools Issue Type: Feature Request Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari ▪ day of week(): returns the day of the week according to the Gregorian calendar enumeration: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday ▪ month of year(): returns the month of the year according to the Gregorian calendar enumeration: January, February, March, April, May, June, July, August, September, October, November, December ▪ day of year(): returns the Gregorian number of the day within the year ▪ week of year(): returns the Gregorian number of the week within the year -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-194) Operator does not provide way to expose arbitrary port

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-194?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFWIP-194: ------------------------------------ As I have realized exposing port on container is just informative. Does not prevent of creating service to connect to any port container is listening to. Thus I am dropping priority. [1] https://medium.com/faun/should-i-configure-the-ports-in-kubernetes-deploy... > Operator does not provide way to expose arbitrary port > ------------------------------------------------------ > > Key: WFWIP-194 > URL: https://issues.jboss.org/browse/WFWIP-194 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > Going through non-Operator approach scenarios we have identified Operator is missing this feature: way to expose arbitrary container port, e.g: > - https:8443 > - jolokia:8778 > - debugging:5000 > - dns-ping:8888 > - any app specific port > Could be partially workarounded by `oc port-forward` capability -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-194) Operator does not provide way to expose arbitrary port

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-194?page=com.atlassian.jira.plugin.... ] Martin Choma updated WFWIP-194: ------------------------------- Priority: Minor (was: Blocker) > Operator does not provide way to expose arbitrary port > ------------------------------------------------------ > > Key: WFWIP-194 > URL: https://issues.jboss.org/browse/WFWIP-194 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Minor > Labels: operator > > Going through non-Operator approach scenarios we have identified Operator is missing this feature: way to expose arbitrary container port, e.g: > - https:8443 > - jolokia:8778 > - debugging:5000 > - dns-ping:8888 > - any app specific port > Could be partially workarounded by `oc port-forward` capability -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4558) executable-model doesn't fully parse multi-line pattern

by Toshiya Kobayashi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4558?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi updated DROOLS-4558: -------------------------------------- Git Pull Request: https://github.com/kiegroup/drools/pull/2550 > executable-model doesn't fully parse multi-line pattern > -------------------------------------------------------- > > Key: DROOLS-4558 > URL: https://issues.jboss.org/browse/DROOLS-4558 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.24.0.Final, 7.25.0.Final, 7.26.0.Final, 7.27.0.Final > Environment: - executable-model > Reporter: Toshiya Kobayashi > Assignee: Luca Molteni > Priority: Major > Labels: support > > When a pattern has multiple lines, executable-model doesn't fully parse its conditions. > {noformat} > rule R1 when > $p : Person(age == 30 > || employed == true) > then > end > {noformat} > Looking at the generated Java code, only the first line is parsed. > It doesn't have a problem in 7.23.0.Final so it seems to be a regression after that. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4558) executable-model doesn't fully parse multi-line pattern

by Toshiya Kobayashi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4558?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi updated DROOLS-4558: -------------------------------------- Description: When a pattern has multiple lines, executable-model doesn't fully parse its conditions. {noformat} rule R1 when $p : Person(age == 30 || employed == true) then end {noformat} Looking at the generated Java code, only the first line is parsed. It doesn't have a problem in 7.23.0.Final so it seems to be a regression after that. was: When a pattern has multiple lines, executable-model doesn't fully parse its conditions. {noformat} rule R1 when $p : Person(age == 30 || employed == "true") then end {noformat} Looking at the generated Java code, only the first line is parsed. It doesn't have a problem in 7.23.0.Final so it seems to be a regression after that. > executable-model doesn't fully parse multi-line pattern > -------------------------------------------------------- > > Key: DROOLS-4558 > URL: https://issues.jboss.org/browse/DROOLS-4558 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.24.0.Final, 7.25.0.Final, 7.26.0.Final, 7.27.0.Final > Environment: - executable-model > Reporter: Toshiya Kobayashi > Assignee: Luca Molteni > Priority: Major > Labels: support > > When a pattern has multiple lines, executable-model doesn't fully parse its conditions. > {noformat} > rule R1 when > $p : Person(age == 30 > || employed == true) > then > end > {noformat} > Looking at the generated Java code, only the first line is parsed. > It doesn't have a problem in 7.23.0.Final so it seems to be a regression after that. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4558) executable-model doesn't fully parse multi-line pattern

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-4558: ----------------------------------------- Summary: executable-model doesn't fully parse multi-line pattern Key: DROOLS-4558 URL: https://issues.jboss.org/browse/DROOLS-4558 Project: Drools Issue Type: Bug Components: executable model Affects Versions: 7.27.0.Final, 7.26.0.Final, 7.25.0.Final, 7.24.0.Final Environment: - executable-model Reporter: Toshiya Kobayashi Assignee: Luca Molteni When a pattern has multiple lines, executable-model doesn't fully parse its conditions. {noformat} rule R1 when $p : Person(age == 30 || employed == "true") then end {noformat} Looking at the generated Java code, only the first line is parsed. It doesn't have a problem in 7.23.0.Final so it seems to be a regression after that. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2386) Support for encryption ciphers that require an initialization vector

by Nick Sawadsky (Jira)

[ https://issues.jboss.org/browse/JGRP-2386?page=com.atlassian.jira.plugin.... ] Nick Sawadsky updated JGRP-2386: -------------------------------- Description: By default, Encrypt sets sym_algorithm to "AES". As a result, the default cipher mode is used, which is ECB. ECB encrypts a given plaintext block to the same ciphertext every time, which can allow attackers to see [patterns in messages being exchanged|https://crypto.stackexchange.com/questions/20941/why-shouldnt-i...]. Modes like CBC, that use a random initialization vector (IV) avoid this problem (assuming a different IV is used for each message). It would be good to modify Encrypt to support ciphers that require an IV, such as AES/CBC/PKCS5Padding. was: By default, Encrypt sets sym_algorithm to "AES". As a result, the default cipher mode is used, which is ECB. ECB encrypts a given plaintext block to the same ciphertext every time, which can allow attackers to see [patterns in messages being exchanged|https://crypto.stackexchange.com/questions/20941/why-shouldnt-i...]. Modes like CBC, that use a random initialization vector (IV) are not susceptible to this problem (assuming a different IV is used for each message). It would be good to modify Encrypt to support ciphers that require an IV, such as AES/CBC/PKCS5Padding. > Support for encryption ciphers that require an initialization vector > -------------------------------------------------------------------- > > Key: JGRP-2386 > URL: https://issues.jboss.org/browse/JGRP-2386 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.1.5, 3.6.19 > Reporter: Nick Sawadsky > Assignee: Bela Ban > Priority: Minor > > By default, Encrypt sets sym_algorithm to "AES". As a result, the default cipher mode is used, which is ECB. ECB encrypts a given plaintext block to the same ciphertext every time, which can allow attackers to see [patterns in messages being exchanged|https://crypto.stackexchange.com/questions/20941/why-shouldnt-i...]. > Modes like CBC, that use a random initialization vector (IV) avoid this problem (assuming a different IV is used for each message). > It would be good to modify Encrypt to support ciphers that require an IV, such as AES/CBC/PKCS5Padding. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2386) Support for encryption ciphers that require an initialization vector

by Nick Sawadsky (Jira)

[ https://issues.jboss.org/browse/JGRP-2386?page=com.atlassian.jira.plugin.... ] Nick Sawadsky updated JGRP-2386: -------------------------------- Description: By default, Encrypt sets sym_algorithm to "AES". As a result, the default cipher mode is used, which is ECB. ECB encrypts a given plaintext block to the same ciphertext every time, which can allow attackers to see [patterns in messages being exchanged|https://crypto.stackexchange.com/questions/20941/why-shouldnt-i...]. Modes like CBC, that use a random initialization vector (IV) are not susceptible to this problem (assuming a different IV is used for each message). It would be good to modify Encrypt to support ciphers that require an IV, such as AES/CBC/PKCS5Padding. was: By default, Encrypt sets sym_algorithm to "AES". As a result, the default cipher mode is used, which is ECB. ECB encrypts a given plaintext block to the same ciphertext every time, which can allow attackers to see [patterns in messages being exchanged|https://crypto.stackexchange.com/questions/20941/why-shouldnt-i...]. Modes like CBC, that use a random initialization vector (IV) are not susceptible to this problem, except in the case where a given IV is reused with the same key. It would be good to modify Encrypt to support ciphers that require an IV, such as AES/CBC/PKCS5Padding. > Support for encryption ciphers that require an initialization vector > -------------------------------------------------------------------- > > Key: JGRP-2386 > URL: https://issues.jboss.org/browse/JGRP-2386 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.1.5, 3.6.19 > Reporter: Nick Sawadsky > Assignee: Bela Ban > Priority: Minor > > By default, Encrypt sets sym_algorithm to "AES". As a result, the default cipher mode is used, which is ECB. ECB encrypts a given plaintext block to the same ciphertext every time, which can allow attackers to see [patterns in messages being exchanged|https://crypto.stackexchange.com/questions/20941/why-shouldnt-i...]. > Modes like CBC, that use a random initialization vector (IV) are not susceptible to this problem (assuming a different IV is used for each message). > It would be good to modify Encrypt to support ciphers that require an IV, such as AES/CBC/PKCS5Padding. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2386) Support for encryption ciphers that require an initialization vector

by Nick Sawadsky (Jira)

[ https://issues.jboss.org/browse/JGRP-2386?page=com.atlassian.jira.plugin.... ] Nick Sawadsky updated JGRP-2386: -------------------------------- Description: By default, Encrypt sets sym_algorithm to "AES". As a result, the default cipher mode is used, which is ECB. ECB encrypts a given plaintext block to the same ciphertext every time, which can allow attackers to see [patterns in messages being exchanged|https://crypto.stackexchange.com/questions/20941/why-shouldnt-i...]. Modes like CBC, that use a random initialization vector (IV) are not susceptible to this problem, except in the case where a given IV is reused with the same key. It would be good to modify Encrypt to support ciphers that require an IV, such as AES/CBC/PKCS5Padding. was: By default, Encrypt sets sym_algorithm to "AES". As a result, the default cipher mode is used, which is ECB. ECB encrypts a given plaintext block to the same ciphertext every time, which can give attackers insight into the [types of messages being exchanged|https://crypto.stackexchange.com/questions/20941/why-shouldnt-i...]. Modes like CBC, that use a random initialization vector (IV) are not susceptible to this problem, except in the case where a given IV is reused with the same key. It would be good to modify Encrypt to support ciphers that require an IV, such as AES/CBC/PKCS5Padding. > Support for encryption ciphers that require an initialization vector > -------------------------------------------------------------------- > > Key: JGRP-2386 > URL: https://issues.jboss.org/browse/JGRP-2386 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.1.5, 3.6.19 > Reporter: Nick Sawadsky > Assignee: Bela Ban > Priority: Minor > > By default, Encrypt sets sym_algorithm to "AES". As a result, the default cipher mode is used, which is ECB. ECB encrypts a given plaintext block to the same ciphertext every time, which can allow attackers to see [patterns in messages being exchanged|https://crypto.stackexchange.com/questions/20941/why-shouldnt-i...]. > Modes like CBC, that use a random initialization vector (IV) are not susceptible to this problem, except in the case where a given IV is reused with the same key. > It would be good to modify Encrypt to support ciphers that require an IV, such as AES/CBC/PKCS5Padding. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4513) s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails

by Hiroko Miura (Jira)

[ https://issues.jboss.org/browse/DROOLS-4513?page=com.atlassian.jira.plugi... ] Hiroko Miura commented on DROOLS-4513: -------------------------------------- Hi [~dward], I agree with you that exact solution of s2i build failure is to correct kmodule.xml. But it's really hard to identify what(i.e. failure of schema verification of kmodule.xml) is a cause of s2i build failure from logging current logging. At least, to identify it, I had to run it with debugger on no-openshift environment and it is impossible to do it by customer on openshift environment. Therefore, this is a request to add appropriate logging in this case so that customer can understand why s2i build fails. make sense? (yes, I know this may not be a bug, but rather RFE, but it would be appreciated if we can improve logging as soon as possible.) > s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails > ------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-4513 > URL: https://issues.jboss.org/browse/DROOLS-4513 > Project: Drools > Issue Type: Bug > Components: build, kie server > Affects Versions: 7.14.0.Final, 7.18.0.Final, 7.24.0.Final > Environment: OpenShift 3.11 with rhdm72-prod-immutable-kieserver.yaml/rhdm73-prod-immutable-kieserver.yaml > Reporter: Hiroko Miura > Assignee: Filippe Spolti > Priority: Major > Labels: support > Attachments: ruleTest.zip > > > If multiple ksession are defined in kmodule.xml and Event Lister is set more than one ksession, s2i build fails at KieServerContainerVerifier with the following error. > {noformat} > [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT > java.lang.RuntimeException: Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT > at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186) > at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:172) > at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:65) > at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:53) > at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:40) > at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:119) > at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:101) > at org.jboss.modules.Module.run(Module.java:352) > at org.jboss.modules.Module.run(Module.java:320) > at org.jboss.modules.Main.main(Main.java:593) > [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - com.redhat.gss:ruleTest:1.0.0-SNAPSHOT not verified. > ERROR Aborting due to error code 1 from kie server container verification > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 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 September 2019