February 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (DROOLS-6045) Fix nested groupby

by Mario Fusco (Jira)

Mario Fusco created DROOLS-6045: ----------------------------------- Summary: Fix nested groupby Key: DROOLS-6045 URL: https://issues.redhat.com/browse/DROOLS-6045 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2090) Evidence is not used when getting the realm mapping in ServerAuthenticationContext#assignName

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-2090?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-2090: ---------------------------- Forum Reference: https://groups.google.com/g/wildfly/c/CGh8rdNgqHQ/m/GMQHZ6jlBQAJ > Evidence is not used when getting the realm mapping in ServerAuthenticationContext#assignName > ---------------------------------------------------------------------------------------------- > > Key: ELY-2090 > URL: https://issues.redhat.com/browse/ELY-2090 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Farah Juma > Priority: Major > > The realm mapping is determined in [ServerAuthenticationContext#assignName|https://github.com/wildfly-securit...]. Currently, this does not make use of the {{evidence}} parameter at all. This should be updated to make use of the {{evidence}} parameter so that it gets used in the call to {{realmMapper#getRealmMapping}}. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2090) Evidence is not used when getting the realm mapping in ServerAuthenticationContext#assignName

by Farah Juma (Jira)

Farah Juma created ELY-2090: ------------------------------- Summary: Evidence is not used when getting the realm mapping in ServerAuthenticationContext#assignName Key: ELY-2090 URL: https://issues.redhat.com/browse/ELY-2090 Project: WildFly Elytron Issue Type: Bug Reporter: Farah Juma The realm mapping is determined in [ServerAuthenticationContext#assignName|https://github.com/wildfly-securit...]. Currently, this does not make use of the {{evidence}} parameter at all. This should be updated to make use of the {{evidence}} parameter so that it gets used in the call to {{realmMapper#getRealmMapping}}. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-4827) Errors Missing on Invalid Configuration

by Bartosz Spyrko-Smietanko (Jira)

[ https://issues.redhat.com/browse/WFCORE-4827?page=com.atlassian.jira.plug... ] Bartosz Spyrko-Smietanko commented on WFCORE-4827: -------------------------------------------------- I found there's one more problem - as soon as the FAILURE_DESCRIPTION is set in the first failing ServiceVerificationHelper, the rollback flag will be set in [https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... will prevent any further ServiceVerificationHelpers from running. Maybe in this case SVH could attach something like DEFERED_ROLLBACK flag to the context and if it's present, canContinueProcessing() would allow the VERIFY stage to finish? > Errors Missing on Invalid Configuration > --------------------------------------- > > Key: WFCORE-4827 > URL: https://issues.redhat.com/browse/WFCORE-4827 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Beta7 > Reporter: Darran Lofthouse > Assignee: Richard Opalka > Priority: Critical > Labels: domain-mode > > [~ropalka] I believe this is caused by the MSC refactoring. > Steps, in the default host.xml for domain mode. > 1. Define the following security realm: - > {noformat} > <security-realms> > <security-realm name="ldap_security_realm"> > <server-identities> > <ssl> > <keystore path="generated.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/> > </ssl> > </server-identities> > <authentication> > <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true"> > <username-filter attribute="samaccountname"/> > </ldap> > </authentication> > </security-realm> > {noformat} > 2. Define the following outbound connection: - > {noformat} > <outbound-connections> > <ldap name="testLdap" url="ldap://localhost:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="passowrd" /> > </outbound-connections> > {noformat} > 3. Update the management interfaces to: - > {noformat} > <management-interfaces> > <http-interface security-realm="ldap_security_realm"> > <http-upgrade enabled="true"/> > <socket interface="management" port="${jboss.management.http.port:9990}"/> > </http-interface> > </management-interfaces> > {noformat} > The server fails to boot with just the following error: - > {noformat} > [Host Controller] 17:56:40,052 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {noformat} > If the management interface is then updated to reference the ManagementRealm instead the error is now: - > {noformat} > [Host Controller] 18:01:48,595 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > [Host Controller] ("host" => "master"), > [Host Controller] ("core-service" => "management"), > [Host Controller] ("security-realm" => "ldap_security_realm") > [Host Controller] ]) - failure description: { > [Host Controller] "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"jboss.server.config.dir\""], > [Host Controller] "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.core.management.security.realm.ldap_security_realm.key-manager is missing [jboss.server.path.\"jboss.server.config.dir\"]"] > [Host Controller] } > {noformat} > This error is expected as the realm defined in step 1 referenced an invalid path. > I believe the error reporting should come from this method: - > org.jboss.as.controller.ServiceVerificationHelper.execute(OperationContext, ModelNode) > However something seems to have changes with the MSC migration. > This was recently encountered debugging the bug report in https://issues.redhat.com/browse/WFCORE-4820, if you see an error "Multiple CallbackHandlerServices for the same mechanism (PLAIN)" that has been covered by WFCORE-4820. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[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)

3 years, 10 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)

3 years, 10 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)

3 years, 10 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)

3 years, 10 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)

3 years, 10 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)

3 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2021