July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3485) Misleading failure-description for capabilities in domain

by Moulali Shikalwadi (Jira)

[ https://issues.redhat.com/browse/WFCORE-3485?page=com.atlassian.jira.plug... ] Moulali Shikalwadi commented on WFCORE-3485: -------------------------------------------- [~olukas], [~brian.stansberry] Is this issue still persist? Could you please add some steps to reproduce it. > Misleading failure-description for capabilities in domain > --------------------------------------------------------- > > Key: WFCORE-3485 > URL: https://issues.redhat.com/browse/WFCORE-3485 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 3.0.10.Final > Reporter: Ondrej Lukas > Priority: Minor > > In case when configuration in domain.xml tries to reference any capability from host.xml (or vice versa), but should not be able to reference it then it correctly fails, but there is failure-description which is misleading. > Start domain with default domain.xml and host.xml and run following CLI command and see: > {code} > /profile=full/subsystem=elytron/http-authentication-factory=some-factory:add(http-server-mechanism-factory=global,security-domain=ManagementDomain) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available: > org.wildfly.security.security-domain.ManagementDomain in context 'profile=full'; Possible registration points for this capability: > /host=master/subsystem=elytron/security-domain=* > /profile=*/subsystem=elytron/security-domain=*"}, > "rolled-back" => true > } > {code} > It should show only correct registration point {{/profile=\*/subsystem=elytron/security-domain=\*}}. It is misleading because ManagementDomain capability exists in {{/host=master/subsystem=elytron/security-domain=*}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13575) Remove all hard coded references to Artemis default values

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFLY-13575?page=com.atlassian.jira.plugi... ] Emmanuel Hugonnet commented on WFLY-13575: ------------------------------------------ The goal is to check for changes between current Artemis default and wildFly configuration default when they are not different currently. Those values you found should be excluded for now > Remove all hard coded references to Artemis default values > ---------------------------------------------------------- > > Key: WFLY-13575 > URL: https://issues.redhat.com/browse/WFLY-13575 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Affects Versions: 20.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Michal Petrov > Priority: Major > > There are still attributes that use Artemis default configuration valuues from FileConfiguration for example. > Remove those values so that they are not updated behind the scene and add a test to know when our default values don't align with Artemis ones. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13631) MicroProfile-Health: HealthChecks from WARs within EARs cannot be found

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13631?page=com.atlassian.jira.plugi... ] Jeff Mesnil resolved WFLY-13631. -------------------------------- Resolution: Duplicate Issue Reported issue is tracked by WFLY-12835 > MicroProfile-Health: HealthChecks from WARs within EARs cannot be found > ----------------------------------------------------------------------- > > Key: WFLY-13631 > URL: https://issues.redhat.com/browse/WFLY-13631 > Project: WildFly > Issue Type: Bug > Components: MP Health > Affects Versions: 20.0.0.Final > Reporter: Jens Borrmann > Assignee: Jeff Mesnil > Priority: Major > > We want to make use of Microprofile Health in our applications. These are deployed as EARs (due to customers' demand). HealthChecks from WARs within EARs are not displayed when accessing the health endpoint ([http://localhost:9990/health]) > With a simple example (such as [https://www.adam-bien.com/roller/abien/entry/simplest_possible_microprofi...]) I have the following situation > * Deploying as a WAR: Everything works fine > * Deploying as an EAR (containing the WAR) the following information is displayed: > {"status":"UP","checks":[\{"name":"ready-deployment.myapp.ear.microprofile.war","status":"UP"}]} > Remarks: > * Using the new and not deprecated /health/ready does not change anything > * Using OpenLiberty everything works fine -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3792) org.jboss.remoting module should be private

by Moulali Shikalwadi (Jira)

[ https://issues.redhat.com/browse/WFCORE-3792?page=com.atlassian.jira.plug... ] Moulali Shikalwadi commented on WFCORE-3792: -------------------------------------------- HI [~bmaxwell], Is this issue still persists? Could you please add some steps to reproduce it. > org.jboss.remoting module should be private > ------------------------------------------- > > Key: WFCORE-3792 > URL: https://issues.redhat.com/browse/WFCORE-3792 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Affects Versions: 5.0.0.Alpha4 > Reporter: Brad Maxwell > Priority: Major > > org.jboss.remoting module should be private > /core-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/remoting/main/module.xml -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13680) Generated metrics have duplicate labels

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13680?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFLY-13680: ------------------------------------ I checked that WildFly 19 that upgraded the smallrye-metrics component (in charge of exporting the metrics) had fixed this issue in WFLY-13022 > Generated metrics have duplicate labels > --------------------------------------- > > Key: WFLY-13680 > URL: https://issues.redhat.com/browse/WFLY-13680 > Project: WildFly > Issue Type: Bug > Components: MP Metrics > Reporter: Ivona Skorjanc > Assignee: Jeff Mesnil > Priority: Major > Attachments: kc_metric.txt > > > We are using Keycloak which generates metrics using the jBoss CLI: [https://github.com/keycloak/keycloak-containers/blob/master/server/tools/...] > We want to use Telegraf (with the Prometheus input plugin) to read the generated metrics. However, we get the following error: > {{Error in plugin: error reading metrics for [http://localhost:9990/metrics]: reading text format failed: text format parsing error in line 34: second HELP line for metric name "base_gc_total"}} > The base_gc_total metric appears twice for some reason. See the full metrics output in the attachment. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13680) Generated metrics have duplicate labels

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13680?page=com.atlassian.jira.plugi... ] Jeff Mesnil resolved WFLY-13680. -------------------------------- Fix Version/s: 19.0.0.Final Resolution: Done > Generated metrics have duplicate labels > --------------------------------------- > > Key: WFLY-13680 > URL: https://issues.redhat.com/browse/WFLY-13680 > Project: WildFly > Issue Type: Bug > Components: MP Metrics > Reporter: Ivona Skorjanc > Assignee: Jeff Mesnil > Priority: Major > Fix For: 19.0.0.Final > > Attachments: kc_metric.txt > > > We are using Keycloak which generates metrics using the jBoss CLI: [https://github.com/keycloak/keycloak-containers/blob/master/server/tools/...] > We want to use Telegraf (with the Prometheus input plugin) to read the generated metrics. However, we get the following error: > {{Error in plugin: error reading metrics for [http://localhost:9990/metrics]: reading text format failed: text format parsing error in line 34: second HELP line for metric name "base_gc_total"}} > The base_gc_total metric appears twice for some reason. See the full metrics output in the attachment. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13631) MicroProfile-Health: HealthChecks from WARs within EARs cannot be found

by Jens Borrmann (Jira)

[ https://issues.redhat.com/browse/WFLY-13631?page=com.atlassian.jira.plugi... ] Jens Borrmann commented on WFLY-13631: -------------------------------------- Did you already have the chance to look into this issue? > MicroProfile-Health: HealthChecks from WARs within EARs cannot be found > ----------------------------------------------------------------------- > > Key: WFLY-13631 > URL: https://issues.redhat.com/browse/WFLY-13631 > Project: WildFly > Issue Type: Bug > Components: MP Health > Affects Versions: 20.0.0.Final > Reporter: Jens Borrmann > Assignee: Jeff Mesnil > Priority: Major > > We want to make use of Microprofile Health in our applications. These are deployed as EARs (due to customers' demand). HealthChecks from WARs within EARs are not displayed when accessing the health endpoint ([http://localhost:9990/health]) > With a simple example (such as [https://www.adam-bien.com/roller/abien/entry/simplest_possible_microprofi...]) I have the following situation > * Deploying as a WAR: Everything works fine > * Deploying as an EAR (containing the WAR) the following information is displayed: > {"status":"UP","checks":[\{"name":"ready-deployment.myapp.ear.microprofile.war","status":"UP"}]} > Remarks: > * Using the new and not deprecated /health/ready does not change anything > * Using OpenLiberty everything works fine -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4668) Transaction recovery of remote ejb calls should not be using static Default AuthenticationContext

by Moulali Shikalwadi (Jira)

[ https://issues.redhat.com/browse/WFCORE-4668?page=com.atlassian.jira.plug... ] Moulali Shikalwadi commented on WFCORE-4668: -------------------------------------------- [~ochaloup] is this issue still persist? Could you please add some steps to reproduce it. > Transaction recovery of remote ejb calls should not be using static Default AuthenticationContext > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-4668 > URL: https://issues.redhat.com/browse/WFCORE-4668 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Beta9 > Reporter: Ondrej Chaloupka > Priority: Critical > > The issue WFCORE-4599 removed the `AuthenticationContext` would be static. This started to cause troubles for transaction recovery processing when remote ejb calls are invoked. > The configuration that was used earlier for server to server ejb calls[1] (used with `-Dwildfly.config.url`) stopped working. > It was possible to configure the default authentication context in the `standalone.xml` for the whole elytron subsystem (in way like [2]). But this change started to cause threads being stuck on execution of remote ejb calls in WFTC (somewhere here [3]). > Because of that the WFCORE-4659 reverted back the functionality of static global authentication context. This was rather a bit workaround as the functionality should be rather working as Stuart pointed out > {quote} > - Add an explicit config to specify the authentication context used by transaction recovery > - If this is not set fall back to the default authentication context that is used by deployments > - If none of the above are set then the auth context should be empty > {quote} > [1] > {code} > <configuration> > <authentication-client xmlns="urn:elytron:1.0"> > <authentication-rules> > <rule use-configuration="jta"> > <match-abstract-type name="jta" authority="jboss"/> > </rule> > </authentication-rules> > <authentication-configurations> > <configuration name="jta"> > <sasl-mechanism-selector selector="DIGEST-MD5"/> > <providers> > <use-service-loader /> > </providers> > <set-user-name name="ejb"/> > <credentials> > <clear-password password="ejb"/> > </credentials> > <set-mechanism-realm name="ApplicationRealm" /> > </configuration> > </authentication-configurations> > </authentication-client> > </configuration> > {code} > [2] > {code} > <subsystem xmlns="urn:wildfly:elytron:8.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto" default-authentication-context="jta"> > <authentication-client> > <authentication-configuration name="jta" authentication-name="ejb" realm="ApplicationRealm" sasl-mechanism-selector="DIGEST-MD5"> > <credential-reference clear-text="ejb"/> > </authentication-configuration> > <authentication-context name="jta"> > <match-rule match-abstract-type-authority="jboss" authentication-configuration="jta"/> > </authentication-context> > </authentication-client> > {code} > [3] https://github.com/wildfly/wildfly-transaction-client/blob/master/src/mai... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13680) Generated metrics have duplicate labels

by Ivona Skorjanc (Jira)

[ https://issues.redhat.com/browse/WFLY-13680?page=com.atlassian.jira.plugi... ] Ivona Skorjanc commented on WFLY-13680: --------------------------------------- We are using Keycloak 9.0.1 which uses WildFly 18.0.1.Final. > Generated metrics have duplicate labels > --------------------------------------- > > Key: WFLY-13680 > URL: https://issues.redhat.com/browse/WFLY-13680 > Project: WildFly > Issue Type: Bug > Components: MP Metrics > Reporter: Ivona Skorjanc > Assignee: Jeff Mesnil > Priority: Major > Attachments: kc_metric.txt > > > We are using Keycloak which generates metrics using the jBoss CLI: [https://github.com/keycloak/keycloak-containers/blob/master/server/tools/...] > We want to use Telegraf (with the Prometheus input plugin) to read the generated metrics. However, we get the following error: > {{Error in plugin: error reading metrics for [http://localhost:9990/metrics]: reading text format failed: text format parsing error in line 34: second HELP line for metric name "base_gc_total"}} > The base_gc_total metric appears twice for some reason. See the full metrics output in the attachment. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13183) WFLYWELD0041: WeldContainer is not started when redeploying

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-13183?page=com.atlassian.jira.plugi... ] Bartosz Baranowski commented on WFLY-13183: ------------------------------------------- [~rchakrab] Check clones, there is whole thread at the bottom. > WFLYWELD0041: WeldContainer is not started when redeploying > ----------------------------------------------------------- > > Key: WFLY-13183 > URL: https://issues.redhat.com/browse/WFLY-13183 > Project: WildFly > Issue Type: Bug > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 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 July 2020