September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-5116) Bootable JAR, JMX not properly initialized at boot.

by Jean Francois Denise (Jira)

Jean Francois Denise created WFCORE-5116: -------------------------------------------- Summary: Bootable JAR, JMX not properly initialized at boot. Key: WFCORE-5116 URL: https://issues.redhat.com/browse/WFCORE-5116 Project: WildFly Core Issue Type: Bug Components: Bootable JAR Reporter: Jean Francois Denise Assignee: Jean Francois Denise The correct MBeanServer builder must be set for the server's MBeans to be registered in the PlatformMBeanServer. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13679) Make legacy security optional for "org.wildfly.iiop-openjdk"

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13679?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13679: ------------------------------ Description: The dependency needs to optional so provisioning a layer with iiop-openjdk does not automatically pull in legacy security. This is not just about making the module dependency optional, this is about understanding why it is not optional and identifying the steps required to make it optional. This needs to consider: * Default Configuration * User Defined Configuration Both of these can have different consequences depending on of they are used for: * Resource defined services * DeploymentUnitProcessor processing was: The dependency needs to optional so provisioning a layer with batch does not automatically pull in legacy security. This is not just about making the module dependency optional, this is about understanding why it is not optional and identifying the steps required to make it optional. This needs to consider: * Default Configuration * User Defined Configuration Both of these can have different consequences depending on of they are used for: * Resource defined services * DeploymentUnitProcessor processing > Make legacy security optional for "org.wildfly.iiop-openjdk" > ------------------------------------------------------------ > > Key: WFLY-13679 > URL: https://issues.redhat.com/browse/WFLY-13679 > Project: WildFly > Issue Type: Sub-task > Components: IIOP, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 21.0.0.Beta1 > > > The dependency needs to optional so provisioning a layer with iiop-openjdk does not automatically pull in legacy security. > This is not just about making the module dependency optional, this is about understanding why it is not optional and identifying the steps required to make it optional. > This needs to consider: > * Default Configuration > * User Defined Configuration > Both of these can have different consequences depending on of they are used for: > * Resource defined services > * DeploymentUnitProcessor processing -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13820) Make the annoying jaeger 'shutdown hook' logging go away

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13820: --------------------------------------- Summary: Make the annoying jaeger 'shutdown hook' logging go away Key: WFLY-13820 URL: https://issues.redhat.com/browse/WFLY-13820 Project: WildFly Issue Type: Enhancement Components: MP OpenTracing Reporter: Brian Stansberry Assignee: Emmanuel Hugonnet If there's something simple that can be done to make this go away it would be nice. {code} INFO [io.jaegertracing.internal.JaegerTracer] (MSC service thread 1-4) No shutdown hook registered: Please call close() manually on application shutdown. INFO [io.jaegertracing.internal.JaegerTracer] (MSC service thread 1-2) No shutdown hook registered: Please call close() manually on application shutdown. {code} I'm not looking for anything nasty or complex here; feel free to reject this if something like that is needed. Of course if what's it's asking for is something we should be doing but aren't, then this is a bug. :) But I assume whatever it would want done via a shutdown hook is not something an appserver that supports 'reload' would use a shutdown hook to accomplish. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-5115) Allow a properties file which contains system properties to be loaded in the bootable JAR's entry point

by James Perkins (Jira)

James Perkins created WFCORE-5115: ------------------------------------- Summary: Allow a properties file which contains system properties to be loaded in the bootable JAR's entry point Key: WFCORE-5115 URL: https://issues.redhat.com/browse/WFCORE-5115 Project: WildFly Core Issue Type: Enhancement Components: Bootable JAR Reporter: James Perkins Assignee: James Perkins With the fix for [generating a {{logging.properties}} config|https://github.com/wildfly-extras/wildfly-jar-maven-plugin/issues/73] there is a chance properties defined in the {{system-properties}} or {{path}} resource may be needed for the log manager at boot. As part of the mentioned fix a {{boot-config.properties}} file will be generated. The entry point of the bootable JAR should look for this file in the {{$JBOSS_HOME/standalone/configuration}} directory and if found load those system properties before the log manager is configured. Properties passed to via the command line should take precedence over these defined properties as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-5109) Ensure the log manager configurator is attached to the root logger

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-5109?page=com.atlassian.jira.plug... ] James Perkins commented on WFCORE-5109: --------------------------------------- I've made this a blocker as it does cause issues with the logging subsystem where the the logging configuration is overwritten when the logging subsystem is processed. This is an issue when something like a file handler is used and {{append}} is set to {{false}}. The file will be closed and re-opened resulting in missing log messages. > Ensure the log manager configurator is attached to the root logger > ------------------------------------------------------------------ > > Key: WFCORE-5109 > URL: https://issues.redhat.com/browse/WFCORE-5109 > Project: WildFly Core > Issue Type: Bug > Components: Bootable JAR, Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 13.0.0.Final > > > The entry point for the bootable JAR configures a custom log context. The logging subsystem looks on the root logger of that context to locate the {{Configurator}} which was used to configure the context. The configurator should be attached to the root logger so the subsystem locate it. Without this the context will be reconfigured resulting in possible truncation of log messages. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-5109) Ensure the log manager configurator is attached to the root logger

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-5109?page=com.atlassian.jira.plug... ] James Perkins updated WFCORE-5109: ---------------------------------- Priority: Blocker (was: Major) > Ensure the log manager configurator is attached to the root logger > ------------------------------------------------------------------ > > Key: WFCORE-5109 > URL: https://issues.redhat.com/browse/WFCORE-5109 > Project: WildFly Core > Issue Type: Bug > Components: Bootable JAR, Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > > The entry point for the bootable JAR configures a custom log context. The logging subsystem looks on the root logger of that context to locate the {{Configurator}} which was used to configure the context. The configurator should be attached to the root logger so the subsystem locate it. Without this the context will be reconfigured resulting in possible truncation of log messages. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-5109) Ensure the log manager configurator is attached to the root logger

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-5109?page=com.atlassian.jira.plug... ] James Perkins updated WFCORE-5109: ---------------------------------- Fix Version/s: 13.0.0.Final > Ensure the log manager configurator is attached to the root logger > ------------------------------------------------------------------ > > Key: WFCORE-5109 > URL: https://issues.redhat.com/browse/WFCORE-5109 > Project: WildFly Core > Issue Type: Bug > Components: Bootable JAR, Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 13.0.0.Final > > > The entry point for the bootable JAR configures a custom log context. The logging subsystem looks on the root logger of that context to locate the {{Configurator}} which was used to configure the context. The configurator should be attached to the root logger so the subsystem locate it. Without this the context will be reconfigured resulting in possible truncation of log messages. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13774) Difference in OpenTracing subsystem standard configuration leads to the tests failures

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFLY-13774?page=com.atlassian.jira.plugi... ] Emmanuel Hugonnet edited comment on WFLY-13774 at 9/2/20 1:04 PM: ------------------------------------------------------------------ Using env variables the testsuite passes: export JAEGER_SAMPLER_TYPE=const export JAEGER_SAMPLER_PARAM=1.0 This was done to be 'consistent' with previous configuration which was relying on environment variables to configure opentracing. was (Author: ehugonnet): Using env variables the testsuite passes: export JAEGER_SAMPLER_TYPE=const export JAEGER_SAMPLER_PARAM=1.0 This was done to be 'consisten' with previous configuration which was relying on environment variables to configure opentracing. > Difference in OpenTracing subsystem standard configuration leads to the tests failures > --------------------------------------------------------------------------------------- > > Key: WFLY-13774 > URL: https://issues.redhat.com/browse/WFLY-13774 > Project: WildFly > Issue Type: Bug > Components: Build System, MP OpenTracing > Reporter: Sultan Zhantemirov > Assignee: Emmanuel Hugonnet > Priority: Major > > Since OpenTracing has been introduced, `standalone.xml` had the following OT SmallRye subsystem configuration: > {noformat} > <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0" default-tracer="jaeger"> > <jaeger-tracer name="jaeger"> > <sampler-configuration sampler-type="const" sampler-param="1.0"/> > </jaeger-tracer> > </subsystem> > {noformat} > With WildFly 19 and later we also have `standalone-microprofile.xml` configuration file which is used by default in MicroProfile test suite [1]. It has the following configuration: > {noformat} > <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0"/> > {noformat} > As it is recommended in documentation [2] it's better to define missing Jaeger properties (_sampler type _and _sampler param_) in order to sample every request. Sampling every request is needed by MicroProfile test suite OpenTracing basic tests. > A question is: will `standalone-microprofile.xml` configuration file have the wider OT subsystem configuration? Or do the tests have to define additional attributes in subsystem by themselves? > Thank you. > [1] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite#target-distri... > [2] - https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13774) Difference in OpenTracing subsystem standard configuration leads to the tests failures

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFLY-13774?page=com.atlassian.jira.plugi... ] Emmanuel Hugonnet commented on WFLY-13774: ------------------------------------------ Using env variables the testsuite passes: export JAEGER_SAMPLER_TYPE=const export JAEGER_SAMPLER_PARAM=1.0 This was done to be 'consisten' with previous configuration which was relying on environment variables to configure opentracing. > Difference in OpenTracing subsystem standard configuration leads to the tests failures > --------------------------------------------------------------------------------------- > > Key: WFLY-13774 > URL: https://issues.redhat.com/browse/WFLY-13774 > Project: WildFly > Issue Type: Bug > Components: Build System, MP OpenTracing > Reporter: Sultan Zhantemirov > Assignee: Emmanuel Hugonnet > Priority: Major > > Since OpenTracing has been introduced, `standalone.xml` had the following OT SmallRye subsystem configuration: > {noformat} > <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0" default-tracer="jaeger"> > <jaeger-tracer name="jaeger"> > <sampler-configuration sampler-type="const" sampler-param="1.0"/> > </jaeger-tracer> > </subsystem> > {noformat} > With WildFly 19 and later we also have `standalone-microprofile.xml` configuration file which is used by default in MicroProfile test suite [1]. It has the following configuration: > {noformat} > <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0"/> > {noformat} > As it is recommended in documentation [2] it's better to define missing Jaeger properties (_sampler type _and _sampler param_) in order to sample every request. Sampling every request is needed by MicroProfile test suite OpenTracing basic tests. > A question is: will `standalone-microprofile.xml` configuration file have the wider OT subsystem configuration? Or do the tests have to define additional attributes in subsystem by themselves? > Thank you. > [1] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite#target-distri... > [2] - https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-5080) KeyStoresTestCase fails on IBM Java 8

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/WFCORE-5080?page=com.atlassian.jira.plug... ] Sonia Zaldana updated WFCORE-5080: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/4314 > KeyStoresTestCase fails on IBM Java 8 > ------------------------------------- > > Key: WFCORE-5080 > URL: https://issues.redhat.com/browse/WFCORE-5080 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 13.0.0.Beta3 > Reporter: Ricardo Martin Camarero > Assignee: Sonia Zaldana > Priority: Major > > Same issue than WFCORE-5004 but in test case KeyStoresTestCase (inside elytron folder too). It's the same problem with the certificate comparison if using the EMAILADDRESS field. Previously it was hidden by the mock-server issue (WFCORE-5023). > [~szaldana] I'm assigning it to you, it's just repeating what you did for the previous JIRA but for the new class. If you don't have time or prefer that I do the JIRA just assign it back to me. Thanks a lot! -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

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 September 2020