December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB

by Sergiy Barlabanov (JIRA)

[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ] Sergiy Barlabanov commented on WFLY-4198: ----------------------------------------- Yes, we are setting some variables into MDC in the thread, when our code is executed. But the exception above comes from the Wildfly code executed in the thread pool used for async EJB execution before our code is called. And LogDiagnosticContextRecoveryInterceptor is called before any application code is executed so there is no chance to put anything into MDC before LogDiagnosticContextRecoveryInterceptor is called. > NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB > ------------------------------------------------------------------------------------------------ > > Key: WFLY-4198 > URL: https://issues.jboss.org/browse/WFLY-4198 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.0.Final > Reporter: Sergiy Barlabanov > Assignee: David Lloyd > > When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below). > The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap. > So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null. > Currently there is no workaround for that :(. > Caused by: java.lang.NullPointerException > at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97) > at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-92) Fix HTTPS Protocol

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/REMJMX-92?page=com.atlassian.jira.plugin.... ] Philippe Marschall updated REMJMX-92: ------------------------------------- Git Pull Request: https://github.com/jbossas/remoting-jmx/pull/19 > Fix HTTPS Protocol > ------------------ > > Key: REMJMX-92 > URL: https://issues.jboss.org/browse/REMJMX-92 > Project: Remoting JMX > Issue Type: Patch > Components: Connection > Affects Versions: 2.0.1.CR1 > Reporter: Philippe Marschall > Assignee: Darran Lofthouse > > The HTTPS protocol (https-remoting-jmx) is currently not working because of a broken protocol check. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-92) Fix HTTPS Protocol

by Philippe Marschall (JIRA)

Philippe Marschall created REMJMX-92: ---------------------------------------- Summary: Fix HTTPS Protocol Key: REMJMX-92 URL: https://issues.jboss.org/browse/REMJMX-92 Project: Remoting JMX Issue Type: Patch Components: Connection Affects Versions: 2.0.1.CR1 Reporter: Philippe Marschall Assignee: Darran Lofthouse The HTTPS protocol (https-remoting-jmx) is currently not working because of a broken protocol check. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3723) setting the local to english in CLI commands on non-english systems does not produce english output

by Romain Pelisse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3723?page=com.atlassian.jira.plugin.... ] Romain Pelisse commented on WFLY-3723: -------------------------------------- Ok, I've found out the root cause. The issue is that when one ask for en_US, it does find any bundled resources with this prefix - because this is considered the default (hence no appropriate extension): $ find . -name "LocalDescriptions*" | grep org.jboss.as.pojo.LocalDescriptions ./pojo/src/main/resources/org/jboss/as/pojo/LocalDescriptions_de.properties ./pojo/src/main/resources/org/jboss/as/pojo/LocalDescriptions_fr.properties ./pojo/src/main/resources/org/jboss/as/pojo/LocalDescriptions.properties ==> This one contains 'en_US' but not the extension .... However, as default is French (or German), when ask specifically for en_US, no bundle is found, and the JDK falls back to the default Locale (FR or DE), not English. IMHO, the best way to fix that would be to modify the build to copy './pojo/src/main/resources/org/jboss/as/pojo/LocalDescriptions.properties' into ./pojo/src/main/resources/org/jboss/as/pojo/LocalDescriptions.properties_en'. There would be duplication, but only in the generated artefact, and it does sound less cumbersome than having to modify Wildfly code to handle this 'edge cases'. Or maybe someone has a better idea ? > setting the local to english in CLI commands on non-english systems does not produce english output > --------------------------------------------------------------------------------------------------- > > Key: WFLY-3723 > URL: https://issues.jboss.org/browse/WFLY-3723 > Project: WildFly > Issue Type: Bug > Components: Localization > Affects Versions: 8.1.0.Final > Environment: Tested on MacOS running in German > Reporter: Tom Fonteyne > Assignee: Romain Pelisse > Priority: Minor > > A German (or french etc...) system must be used to reproduce. > It is likely this is not limited to MacOS, but I do not have a non-english Linux system available > An out of the box install of wildfly/EAP: > Without configuration, the log file is in German as expected. > Using these CLI comands: > :read-operation-description(name=stop-servers,locale=de_DE) -> german > :read-operation-description(name=stop-servers,locale=en_US) -> german > :read-operation-description(name=stop-servers,locale=fr_FR) -> french > So we cannot get the CLI to produce english output > when configuring JAVA_OPTS in domain.conf with: > JAVA_OPTS="$JAVA_OPTS -Duser.language=en -Duser.country=DE -Duser.encoding=utf-8 > The log is now in English -> works as expected; and: > :read-operation-description(name=stop-servers,locale=de_DE) -> german > :read-operation-description(name=stop-servers,locale=en_US) -> english > So it seems we have a bug where the locale set to start the domain takes precedence over the locale set in the CLI command (but only when English is asked) > I presume this is because English is the default locale. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ] jaikiran pai commented on WFLY-4198: ------------------------------------ I haven't looked at this, but since you note that this is blocking your application usage without any workaround, have you tried explicitly setting something into the MDC using whatever logging framework you are using? Or is there no chance you can do this because this happens on an async EJB invocation thread even before it gets to the point where you can set something? > NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB > ------------------------------------------------------------------------------------------------ > > Key: WFLY-4198 > URL: https://issues.jboss.org/browse/WFLY-4198 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.0.Final > Reporter: Sergiy Barlabanov > Assignee: David Lloyd > > When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below). > The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap. > So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null. > Currently there is no workaround for that :(. > Caused by: java.lang.NullPointerException > at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97) > at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ] jaikiran pai updated WFLY-4198: ------------------------------- Issue Type: Bug (was: Feature Request) > NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB > ------------------------------------------------------------------------------------------------ > > Key: WFLY-4198 > URL: https://issues.jboss.org/browse/WFLY-4198 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.0.Final > Reporter: Sergiy Barlabanov > Assignee: David Lloyd > > When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below). > The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap. > So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null. > Currently there is no workaround for that :(. > Caused by: java.lang.NullPointerException > at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97) > at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-650) Sequential Phreak is broken

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-650?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-650: ------------------------------------------------ Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1168746|https://bugzilla.redhat.com/show_bug.cgi?id=1168746] from VERIFIED to MODIFIED > Sequential Phreak is broken > ---------------------------- > > Key: DROOLS-650 > URL: https://issues.jboss.org/browse/DROOLS-650 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.0.1.Final, 6.1.0.Final, 6.2.0.CR2 > Reporter: Mark Proctor > Assignee: Mario Fusco > Fix For: 6.2.0.CR3 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-489) The "access-mechanism" field in the active-operation resources is always undefined

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-489?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-489: ------------------------------------ Priority: Minor (was: Major) > The "access-mechanism" field in the active-operation resources is always undefined > ---------------------------------------------------------------------------------- > > Key: WFCORE-489 > URL: https://issues.jboss.org/browse/WFCORE-489 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha15 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 1.0.0.Alpha16 > > > The "access-mechanism" field in core-service=management/service=active-operations/active-operation=* is always undefined. The code that sets it is using the wrong var: > {code} > ModelNode accessMechanismNode = model.get(ACCESS_MECHANISM); > if (accessMechanism != null) { > accessMechanismNode.set(accessMechanismNode.toString()); > } > {code} > It should be accessMechanism.toString() -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-489) The "access-mechanism" field in the active-operation resources is always undefined

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-489: --------------------------------------- Summary: The "access-mechanism" field in the active-operation resources is always undefined Key: WFCORE-489 URL: https://issues.jboss.org/browse/WFCORE-489 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha15 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 1.0.0.Alpha16 The "access-mechanism" field in core-service=management/service=active-operations/active-operation=* is always undefined. The code that sets it is using the wrong var: {code} ModelNode accessMechanismNode = model.get(ACCESS_MECHANISM); if (accessMechanism != null) { accessMechanismNode.set(accessMechanismNode.toString()); } {code} It should be accessMechanism.toString() -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4202) Domain-level logger category add does not behave as documented

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFLY-4202?page=com.atlassian.jira.plugin.... ] Alexey Loubyansky closed WFLY-4202. ----------------------------------- Resolution: Rejected It's not about the add operation. Relative paths are supported with ./ And this is a way to differentiate between the operations requests (your case) and commands. There is a bit on the difference between the two here https://developer.jboss.org/wiki/CommandLineInterface > Domain-level logger category add does not behave as documented > -------------------------------------------------------------- > > Key: WFLY-4202 > URL: https://issues.jboss.org/browse/WFLY-4202 > Project: WildFly > Issue Type: Bug > Components: CLI, Domain Management > Affects Versions: 8.2.0.Final > Reporter: Arcadiy Ivanov > Assignee: Alexey Loubyansky > > {noformat} > [domain@localhost:9990 /] profile=full-ha-osgi/subsystem=logging/logger=org.jboss.weld:add > 'profile=full-ha-osgi/subsystem=logging/logger=org.jboss.weld:add' is not a valid operation name. > {noformat} > According to the [documentation|https://docs.jboss.org/author/display/WFLY8/How+To#HowTo-Ho...] the above should work -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2014