February 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (DROOLS-6044) DRLX parser: update condition/consequence syntax

by Edoardo Vacchi (Jira)

Edoardo Vacchi created DROOLS-6044: -------------------------------------- Summary: DRLX parser: update condition/consequence syntax Key: DROOLS-6044 URL: https://issues.redhat.com/browse/DROOLS-6044 Project: Drools Issue Type: Task Components: core engine Reporter: Edoardo Vacchi Assignee: Edoardo Vacchi Fix For: 7.51.0.Final Update DRLX: following the latest updates to the spec, add support for comma-separated statements -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-11638) MP Metrics - sort alphabetically /metrics output

by Jason Lee (Jira)

[ https://issues.redhat.com/browse/WFLY-11638?page=com.atlassian.jira.plugi... ] Jason Lee resolved WFLY-11638. ------------------------------ Resolution: Cannot Reproduce > MP Metrics - sort alphabetically /metrics output > ------------------------------------------------ > > Key: WFLY-11638 > URL: https://issues.redhat.com/browse/WFLY-11638 > Project: WildFly > Issue Type: Enhancement > Components: MP Metrics > Reporter: Rostislav Svoboda > Assignee: Jason Lee > Priority: Major > > MP Metrics - sort alphabetically /metrics output > When playing with https://github.com/wildfly/wildfly/pull/11949 I got upset about metrics not being sorted alphabetically or at least grouped together. > My use case was to look at wildfly_undertow_** metrics via browser. > base: and vendor: metrics are grouped together, WF subsystem metrics not - e.g. wildfly_undertow_** metrics were listed on 4 different places. > If alphabetical order is not easy to be achieved, subsystem metrics should be at least grouped together. > I know machines do not care about the order, but people have to look at /metrics too (from time to time ...). -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14457) Modules declaring dependency on CDI should get access to common annotations as well

by Matěj Novotný (Jira)

[ https://issues.redhat.com/browse/WFLY-14457?page=com.atlassian.jira.plugi... ] Matěj Novotný updated WFLY-14457: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/14014 > Modules declaring dependency on CDI should get access to common annotations as well > ----------------------------------------------------------------------------------- > > Key: WFLY-14457 > URL: https://issues.redhat.com/browse/WFLY-14457 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Reporter: Matěj Novotný > Assignee: Matěj Novotný > Priority: Major > Fix For: 23.0.0.Beta1 > > > The actual POM dependency chain in CDI is: > CDI -> interceptors API -> common annotations API > > However, WFLY modules don't mimic this and WFLY modules depending on CDI need to explicitly depend on common annotations in order to enable functionalities such as {{@PreDestroy}} on their beans (which is how we discovered this as part of WFLY-13588). > > There are two solutions: > # Change interceptors module to depend on common annotations and export it > ## This is more complex because they each exist in different project (wfly versus core) > ## Furthermore, interceptors likely only have the dependency because of javadoc > # We add common annotations as CDI module dependency and export is > ## After chat with Brian, we chose this as the go-to solution -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-4584) Include the new wildfly-elytron-encryption module

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4584?page=com.atlassian.jira.plug... ] Jeff Mesnil resolved WFCORE-4584. --------------------------------- Fix Version/s: 15.0.0.Beta1 Resolution: Done > Include the new wildfly-elytron-encryption module > ------------------------------------------------- > > Key: WFCORE-4584 > URL: https://issues.redhat.com/browse/WFCORE-4584 > Project: WildFly Core > Issue Type: Sub-task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 15.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFWIP-373) :resolve-expression does not resolve encrypted expressions

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-373?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFWIP-373: ---------------------------------------- [~dlofthouse] Note resolving is not a bug. It is by design. We should not support resolving via a management API call, and the resolve-expressions op is specifically meant to not do that. If the credential-store handling is different from vault (e.g. the weird result" => ":RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB") then that is something to fix for this RFE. If vault behaves the same way, then it's a general, low-priority, bug to not do the weird stripping of the vault equivalent of ENC: Simply returning the unresolved expression is IMHO ok. IIRC that is what we decided to do, with due consideration first. Doing something else would be an enhancement. > :resolve-expression does not resolve encrypted expressions > ---------------------------------------------------------- > > Key: WFWIP-373 > URL: https://issues.redhat.com/browse/WFWIP-373 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Priority: Major > > The {{:resolve-expression}} operation does not resolve encrypted expressions. > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/expression=encryption:read-resource > { > "outcome" => "success", > "result" => { > "default-resolver" => "Default", > "prefix" => "ENC", > "resolvers" => [ > { > "name" => "Default", > "credential-store" => "credentialstorethree", > "secret-key" => "secretkey" > }, > { > "name" => "resolver2", > "credential-store" => "credentialstorethree", > "secret-key" => "secretkey2" > } > ] > } > } > [standalone@localhost:9990 /] /subsystem=elytron/expression=encryption:create-expression(clear-text=CredentialStoreTwoPassword) > { > "outcome" => "success", > "result" => {"expression" => "${ENC::RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB}"} > } > [standalone@localhost:9990 /] :resolve-expression(expression="${ENC::RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB}") > { > "outcome" => "success", > "result" => ":RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB" > } > {noformat} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14457) Modules declaring dependency on CDI should get access to common annotations as well

by Matěj Novotný (Jira)

Matěj Novotný created WFLY-14457: ------------------------------------ Summary: Modules declaring dependency on CDI should get access to common annotations as well Key: WFLY-14457 URL: https://issues.redhat.com/browse/WFLY-14457 Project: WildFly Issue Type: Bug Components: CDI / Weld Reporter: Matěj Novotný Assignee: Matěj Novotný Fix For: 23.0.0.Beta1 The actual POM dependency chain in CDI is: CDI -> interceptors API -> common annotations API However, WFLY modules don't mimic this and WFLY modules depending on CDI need to explicitly depend on common annotations in order to enable functionalities such as {{@PreDestroy}} on their beans (which is how we discovered this as part of WFLY-13588). There are two solutions: # Change interceptors module to depend on common annotations and export it ## This is more complex because they each exist in different project (wfly versus core) ## Furthermore, interceptors likely only have the dependency because of javadoc # We add common annotations as CDI module dependency and export is ## After chat with Brian, we chose this as the go-to solution -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFWIP-378) The error message from export-secret-key on (secret-key-)credential-store should be more helpful

by Ondrej Kotek (Jira)

Ondrej Kotek created WFWIP-378: ---------------------------------- Summary: The error message from export-secret-key on (secret-key-)credential-store should be more helpful Key: WFWIP-378 URL: https://issues.redhat.com/browse/WFWIP-378 Project: WildFly WIP Issue Type: Bug Components: Security Reporter: Ondrej Kotek Assignee: Darran Lofthouse The error message from the {{export-secret-key}} operation on the {{credential-store}} and {{secret-key-credential-store}} resources should be more helpful when exporting invalid alias {noformat} [standalone@localhost:9990 /] /subsystem=elytron/secret-key-credential-store=b:read-aliases { "outcome" => "success", "result" => ["key"] } [standalone@localhost:9990 /] /subsystem=elytron/secret-key-credential-store=b:export-secret-key(alias=key2) { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: value is null", "rolled-back" => true } {noformat} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14456) Remove Java EE References from the i18n strings

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-14456?page=com.atlassian.jira.plugi... ] Yeray Borges Santana reassigned WFLY-14456: ------------------------------------------- Assignee: Ranabir Chakraborty (was: Yeray Borges Santana) > Remove Java EE References from the i18n strings > ----------------------------------------------- > > Key: WFLY-14456 > URL: https://issues.redhat.com/browse/WFLY-14456 > Project: WildFly > Issue Type: Task > Components: Server > Reporter: Yeray Borges Santana > Assignee: Ranabir Chakraborty > Priority: Major > > Replace Java EE References from the i18n strings. Those strings are in the various XXXLogger.java files and the LocalDescriptions.properties files. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFWIP-376) The error message from import-secret-key on (secret-key-)credential-store should be more helpful

by Ondrej Kotek (Jira)

[ https://issues.redhat.com/browse/WFWIP-376?page=com.atlassian.jira.plugin... ] Ondrej Kotek updated WFWIP-376: ------------------------------- Description: The error message from the {{import-secret-key}} operation on the {{credential-store}} and {{secret-key-credential-store}} resources should be more helpful when importing invalid key (truncated in this case) {noformat} [standalone@localhost:9990 /] /subsystem=elytron/credential-store=a:import-secret-key(alias=a2,key=RUxZA) { "outcome" => "failed", "failure-description" => "COM00501: Expected padding", "rolled-back" => true } {noformat} The same message appears when loading a file with a corrupted key. was: The error message from the {{import-secret-key}} operation on the {{credential store}} resourece should be more helpful when importing invalid key (truncated in this case) {noformat} [standalone@localhost:9990 /] /subsystem=elytron/credential-store=a:import-secret-key(alias=a2,key=RUxZA) { "outcome" => "failed", "failure-description" => "COM00501: Expected padding", "rolled-back" => true } {noformat} The same message appears when loading a file with a corrupted key. > The error message from import-secret-key on (secret-key-)credential-store should be more helpful > ------------------------------------------------------------------------------------------------ > > Key: WFWIP-376 > URL: https://issues.redhat.com/browse/WFWIP-376 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Priority: Critical > > The error message from the {{import-secret-key}} operation on the {{credential-store}} and {{secret-key-credential-store}} resources should be more helpful when importing invalid key (truncated in this case) > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/credential-store=a:import-secret-key(alias=a2,key=RUxZA) > { > "outcome" => "failed", > "failure-description" => "COM00501: Expected padding", > "rolled-back" => true > } > {noformat} > The same message appears when loading a file with a corrupted key. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFWIP-374) (secret-key-)credential-store overwrites existing aliases when generating or importing keys

by Ondrej Kotek (Jira)

[ https://issues.redhat.com/browse/WFWIP-374?page=com.atlassian.jira.plugin... ] Ondrej Kotek updated WFWIP-374: ------------------------------- Summary: (secret-key-)credential-store overwrites existing aliases when generating or importing keys (was: credential-store overwrites existing aliases when generating or importing keys) > (secret-key-)credential-store overwrites existing aliases when generating or importing keys > ------------------------------------------------------------------------------------------- > > Key: WFWIP-374 > URL: https://issues.redhat.com/browse/WFWIP-374 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Priority: Critical > > The Elytron {{credential-store}} resource overwrites existing aliases when generating or importing keys, this is not consistent with the behaviour of the {{add-alias}} operation. > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/credential-store=a:generate-secret-key(alias=a1) > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=elytron/credential-store=a:read-aliases > { > "outcome" => "success", > "result" => ["a1"] > } > [standalone@localhost:9990 /] /subsystem=elytron/credential-store=a:generate-secret-key(alias=a1) > {"outcome" => "success"} > ------------------------- > [standalone@localhost:9990 /] /subsystem=elytron/credential-store=a:export-secret-key(alias=a2) > { > "outcome" => "success", > "result" => {"key" => "RUxZAUuJqp+mNwIEDMrUz0iK6dyG"} > } > [standalone@localhost:9990 /] /subsystem=elytron/credential-store=a:import-secret-key(alias=a2,key=RUxZAUuJqp+mNwIEDMrUz0iK6dyG) > {"outcome" => "success"} > ------------------------- > [standalone@localhost:9990 /] /subsystem=elytron/credential-store=a:add-alias(alias=a2,secret-value=a2) > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=elytron/credential-store=a:add-alias(alias=a2,secret-value=a2) > { > "outcome" => "failed", > "failure-description" => "WFLYELY00913: Credential alias 'a2' of credential type 'org.wildfly.security.credential.PasswordCredential' already exists in the store", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2021