May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3787) JMX audit logging should support all the handlers supported by core audit logging

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3787?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-3787: ------------------------------------------ For any changes in this area it may be good to start some discussions with [~jamezp] and the WildFly Elytron engineers. We have quite a bit of duplication around auditing as well as overlap into the general area of logging so probably should be agreeing a high level strategy. > JMX audit logging should support all the handlers supported by core audit logging > --------------------------------------------------------------------------------- > > Key: WFCORE-3787 > URL: https://issues.jboss.org/browse/WFCORE-3787 > Project: WildFly Core > Issue Type: Feature Request > Components: JMX > Affects Versions: 5.0.0.Alpha5 > Reporter: Yeray Borges > Assignee: Yeray Borges > > Users can enable audit logging for the management interfaces, which will log all operations performed using the management console, management CLI, or custom application that uses the Management API. > JMX subsystem can use the handlers defined for audit logging, but at this moment, only {{file-handler}} and {{syslog-handler}} can be used in JMX subsystem. > This issue will extend the list of supported handlers for JMX subsystem to all handlers supported by core audit logging. > The handlers supported by core audit logging are: > * file-handler > * in-memory-handler > * periodic-rotating-file-handler > * size-rotating-file-handler > * syslog-handler -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-7) CLI argument --no-color-output has no precedence before XML configuration

by Erich Duda (JIRA)

[ https://issues.jboss.org/browse/WFWIP-7?page=com.atlassian.jira.plugin.sy... ] Erich Duda commented on WFWIP-7: -------------------------------- I developed test for this issue, see my branch - https://github.com/dudaerich/wildfly-core/tree/WFCORE-3577 > CLI argument --no-color-output has no precedence before XML configuration > ------------------------------------------------------------------------- > > Key: WFWIP-7 > URL: https://issues.jboss.org/browse/WFWIP-7 > Project: WildFly WIP > Issue Type: Bug > Reporter: Erich Duda > Assignee: Ingo Weiss > Labels: WFCORE-3577 > > When I uncommented {{color-output}} configuration in jboss-cli.xml where {{enabled}} option is set on {{true}}, the {{--no-color-output}} option had not effect. The colors were displayed. > {code:xml|title=jboss-cli.xml} > <color-output> > <enabled>true</enabled> > <error-color>red</error-color> > <warn-color>yellow</warn-color> > <success-color>default</success-color> > <required-color>magenta</required-color> > <workflow-color>default</workflow-color> > <prompt-color>default</prompt-color> > </color-output> > {code} > {code:title=Bash command} > $ ./jboss-cli.sh --no-color-output > {code} > In this case the {{--no-color-output}} should have precedence and no colors should be displayed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-6) Color output cannot be disabled by jboss-cli.xml

by Erich Duda (JIRA)

[ https://issues.jboss.org/browse/WFWIP-6?page=com.atlassian.jira.plugin.sy... ] Erich Duda commented on WFWIP-6: -------------------------------- I developed test for this issue, see my branch - https://github.com/dudaerich/wildfly-core/tree/WFCORE-3577 > Color output cannot be disabled by jboss-cli.xml > ------------------------------------------------ > > Key: WFWIP-6 > URL: https://issues.jboss.org/browse/WFWIP-6 > Project: WildFly WIP > Issue Type: Bug > Reporter: Erich Duda > Assignee: Ingo Weiss > Labels: WFCORE-3577 > > When I disabled color output in {{jboss-cli.xml}} using following configuration, the colors were still displayed. > {code:xml} > <color-output> > <enabled>false</enabled> > </color-output> > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-7) CLI argument --no-color-output has no precedence before XML configuration

by Erich Duda (JIRA)

Erich Duda created WFWIP-7: ------------------------------ Summary: CLI argument --no-color-output has no precedence before XML configuration Key: WFWIP-7 URL: https://issues.jboss.org/browse/WFWIP-7 Project: WildFly WIP Issue Type: Bug Reporter: Erich Duda Assignee: Ingo Weiss When I uncommented {{color-output}} configuration in jboss-cli.xml where {{enabled}} option is set on {{true}}, the {{--no-color-output}} option had not effect. The colors were displayed. {code:xml|title=jboss-cli.xml} <color-output> <enabled>true</enabled> <error-color>red</error-color> <warn-color>yellow</warn-color> <success-color>default</success-color> <required-color>magenta</required-color> <workflow-color>default</workflow-color> <prompt-color>default</prompt-color> </color-output> {code} {code:title=Bash command} $ ./jboss-cli.sh --no-color-output {code} In this case the {{--no-color-output}} should have precedence and no colors should be displayed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-6) Color output cannot be disabled by jboss-cli.xml

by Erich Duda (JIRA)

Erich Duda created WFWIP-6: ------------------------------ Summary: Color output cannot be disabled by jboss-cli.xml Key: WFWIP-6 URL: https://issues.jboss.org/browse/WFWIP-6 Project: WildFly WIP Issue Type: Bug Reporter: Erich Duda Assignee: Ingo Weiss When I disabled color output in {{jboss-cli.xml}} using following configuration, the colors were still displayed. {code:xml} <color-output> <enabled>false</enabled> </color-output> {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-5) Prompt behaves differently with color ouput and without it

by Erich Duda (JIRA)

Erich Duda created WFWIP-5: ------------------------------ Summary: Prompt behaves differently with color ouput and without it Key: WFWIP-5 URL: https://issues.jboss.org/browse/WFWIP-5 Project: WildFly WIP Issue Type: Bug Reporter: Erich Duda Assignee: Ingo Weiss When I run the CLI with option {{--no-color-output}}, the batch or workflow mode is not highlighted by changing of prompt. {code} [disconnected /] batch [disconnected /] {code} If I do the same with colors enabled, the batch mode adds extra # character into the prompt. {code} [disconnected /] batch [disconnected / #] {code} The behavior is inconsistent. There is no reason to add # character to prompt only in color enabled mode. The same applies for if/for/try commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10278) Bean discovery in deployment dependencies (modules) fails to inject from static module-alias's exported dependency

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-10278?page=com.atlassian.jira.plugin... ] Lin Gao updated WFLY-10278: --------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/11161 > Bean discovery in deployment dependencies (modules) fails to inject from static module-alias's exported dependency > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-10278 > URL: https://issues.jboss.org/browse/WFLY-10278 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Reporter: Lin Gao > Assignee: Bartosz Spyrko-Śmietanko > Priority: Critical > Labels: downstream_dependency > > WAR CDI bean is failing to inject a CDI bean from a module-alias exported dependency. war -module-alias -> static module X -> static module Y (containing CDI Beans) > A WAR uses a module-alias with the slot attribute. This module-alias is referenced in jboss-deployment-structure.xml: > {code:java} > <jboss-deployment-structure> > <deployment> > <dependencies> > <module name="mycompany.test.CDIJarMaven" slot="moduloAliasError" meta-inf="export" annotations="true" /> > </dependencies> > </deployment> > </jboss-deployment-structure> > {code} > moduleAliasError which the app has the target moduloNivel2: > {code} > <module-alias xmlns="urn:jboss:module:1.1" name="mycompany.test.CDIJarMaven" slot="moduloAliasError" target-name="mycompany.test.CDIJarMaven" target-slot="moduloNivel2"/> > {code} > moduloNivel2 which the modulo-alias references depends on main module and is including/exporting META-INF where the beans.xml is located: > {code:java} > <module xmlns="urn:jboss:module:1.5" name="mycompany.test.CDIJarMaven"> > <resources> > <resource-root path="CDIJarMaven.jar"/> > </resources> > <dependencies> > <module name="javax.faces.api" export="true"/> > >  > <module name="javax.ejb.api"/> > <module name="javax.enterprise.api" /> > </dependencies> > </module> > {code:java} > modulo main contains the jar with the CDI beans and has a META-INF/beans.xml in it: > {code:java} > <module xmlns="urn:jboss:module:1.1" name="mycompany.test.CDIJarMaven" slot="moduloNivel2"> > <dependencies> > <module name="mycompany.test.CDIJarMaven" slot="main" export="true"> > <imports> > <include path="META-INF**" /> > </imports> > <exports> > <include path="META-INF**" /> > </exports> > </module> > </dependencies> > </module> > {code} > The error we get is: > {code:java} > WELD-001408: Unsatisfied dependencies for type PruebaDTO with qualifiers @Default > at injection point [BackedAnnotatedField] @Inject private backingbeans.Page1.paginacion > at backingbeans.Page1.paginacion(Page1.java:0) > {code} > Checking the code one can see how the beans.xml is seen : > {code:java} > EXTERNAL BeanDeploymentArchive (awar-mock02.war.external.jar:file:/jboss-eap-7.1/modules/mycompany/test/CDIJarMaven/main/CDIJarMaven.jar!/META-INF/beans.xml) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10278) Bean discovery in deployment dependencies (modules) fails to inject from static module-alias's exported dependency

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-10278?page=com.atlassian.jira.plugin... ] Lin Gao reassigned WFLY-10278: ------------------------------ Assignee: Bartosz Spyrko-Śmietanko > Bean discovery in deployment dependencies (modules) fails to inject from static module-alias's exported dependency > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-10278 > URL: https://issues.jboss.org/browse/WFLY-10278 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Reporter: Lin Gao > Assignee: Bartosz Spyrko-Śmietanko > Priority: Critical > Labels: downstream_dependency > > WAR CDI bean is failing to inject a CDI bean from a module-alias exported dependency. war -module-alias -> static module X -> static module Y (containing CDI Beans) > A WAR uses a module-alias with the slot attribute. This module-alias is referenced in jboss-deployment-structure.xml: > {code:java} > <jboss-deployment-structure> > <deployment> > <dependencies> > <module name="mycompany.test.CDIJarMaven" slot="moduloAliasError" meta-inf="export" annotations="true" /> > </dependencies> > </deployment> > </jboss-deployment-structure> > {code} > moduleAliasError which the app has the target moduloNivel2: > {code} > <module-alias xmlns="urn:jboss:module:1.1" name="mycompany.test.CDIJarMaven" slot="moduloAliasError" target-name="mycompany.test.CDIJarMaven" target-slot="moduloNivel2"/> > {code} > moduloNivel2 which the modulo-alias references depends on main module and is including/exporting META-INF where the beans.xml is located: > {code:java} > <module xmlns="urn:jboss:module:1.5" name="mycompany.test.CDIJarMaven"> > <resources> > <resource-root path="CDIJarMaven.jar"/> > </resources> > <dependencies> > <module name="javax.faces.api" export="true"/> > >  > <module name="javax.ejb.api"/> > <module name="javax.enterprise.api" /> > </dependencies> > </module> > {code:java} > modulo main contains the jar with the CDI beans and has a META-INF/beans.xml in it: > {code:java} > <module xmlns="urn:jboss:module:1.1" name="mycompany.test.CDIJarMaven" slot="moduloNivel2"> > <dependencies> > <module name="mycompany.test.CDIJarMaven" slot="main" export="true"> > <imports> > <include path="META-INF**" /> > </imports> > <exports> > <include path="META-INF**" /> > </exports> > </module> > </dependencies> > </module> > {code} > The error we get is: > {code:java} > WELD-001408: Unsatisfied dependencies for type PruebaDTO with qualifiers @Default > at injection point [BackedAnnotatedField] @Inject private backingbeans.Page1.paginacion > at backingbeans.Page1.paginacion(Page1.java:0) > {code} > Checking the code one can see how the beans.xml is seen : > {code:java} > EXTERNAL BeanDeploymentArchive (awar-mock02.war.external.jar:file:/jboss-eap-7.1/modules/mycompany/test/CDIJarMaven/main/CDIJarMaven.jar!/META-INF/beans.xml) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3787) JMX audit logging should support all the handlers supported by core audit logging

by Yeray Borges (JIRA)

Yeray Borges created WFCORE-3787: ------------------------------------ Summary: JMX audit logging should support all the handlers supported by core audit logging Key: WFCORE-3787 URL: https://issues.jboss.org/browse/WFCORE-3787 Project: WildFly Core Issue Type: Feature Request Components: JMX Affects Versions: 5.0.0.Alpha5 Reporter: Yeray Borges Assignee: Yeray Borges Users can enable audit logging for the management interfaces, which will log all operations performed using the management console, management CLI, or custom application that uses the Management API. JMX subsystem can use the handlers defined for audit logging, but at this moment, only {{file-handler}} and {{syslog-handler}} can be used in JMX subsystem. This issue will extend the list of supported handlers for JMX subsystem to all handlers supported by core audit logging. The handlers supported by core audit logging are: * file-handler * in-memory-handler * periodic-rotating-file-handler * size-rotating-file-handler * syslog-handler -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1572) japicmp force source compatibility, but only binary compatibility is required

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1572?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1572: ---------------------------- Description: As part of ELY-1523 japicmp was configured to force binary and source compatibility. By last discussion, only binary compatibility is required. {panel} *Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible... *Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people {panel} Japicmp currently reports adding default method into interface as source incompatible change (see https://github.com/siom79/japicmp/issues/201) -> blocks adding IV into MaskedPassword in ELY-867 was: As part of ELY-1523 japicmp was configured to force binary and source compatibility. By last discussion, only binary compatibility is required. {panel} *Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible... *Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people {panel} Japicmp currently reports adding default method into interface as source incompatible change (see https://github.com/siom79/japicmp/issues/201) -> blocks adding IV into MaskedPassword in ELY-867 > japicmp force source compatibility, but only binary compatibility is required > ----------------------------------------------------------------------------- > > Key: ELY-1572 > URL: https://issues.jboss.org/browse/ELY-1572 > Project: WildFly Elytron > Issue Type: Bug > Components: Build > Affects Versions: 1.3.0.Final > Reporter: Jan Kalina > Assignee: Jan Kalina > > As part of ELY-1523 japicmp was configured to force binary and source compatibility. > By last discussion, only binary compatibility is required. > {panel} > *Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible... > *Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people > {panel} > Japicmp currently reports adding default method into interface as source incompatible change (see https://github.com/siom79/japicmp/issues/201) -> blocks adding IV into MaskedPassword in ELY-867 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 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 May 2018