[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 reopened WFLY-4198:
-------------------------------------
I admit that we fail to reproduce it with a simple example.
But anyway the NullPointer is there.
And the bug is there. JBoss Logging does not expect null coming from SLF4J on that place (org.jboss.logging.MDC#getMap()).
SLF4J API says clearly that it may return a null - see javadoc of org.slf4j.MDC#getCopyOfContextMap(). So JBoss Logging has to respect this and have to check the returned value for null.
I attach the necessary patch for that (the patch is based on jboss-logging 3.1.4.GA).
> 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: Bartosz Baranowski
>
> 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 :(.
> {noformat}
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFCORE-626) Global list-get operation can inadvertently create list elements
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-626?page=com.atlassian.jira.plugin... ]
Tomaz Cerar reopened WFCORE-626:
--------------------------------
Assignee: Tomaz Cerar (was: Paul Ferraro)
Reopening and assigning to me to add test case for this.
Fix was already merged.
> Global list-get operation can inadvertently create list elements
> ----------------------------------------------------------------
>
> Key: WFCORE-626
> URL: https://issues.jboss.org/browse/WFCORE-626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Tomaz Cerar
> Fix For: 1.0.0.CR1
>
>
> Consider the following sequence of operations:
> # :list-clear(name=attribute)
> # :list-get(name=attribute, index=0)
> # :list-add(name=attribute, value=test)
> # :list-get(name=attribute, index=0)
> #2 will return <undefined> as expected. The expected result of #4 is "test". However, it returns <undefined>. This is because #2 will create the missing element at index 0 causing #3 to operate on index 1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4487) Unable to inject Web Service Context into CDI Interceptor
by Mustafa Musaji (JIRA)
[ https://issues.jboss.org/browse/WFLY-4487?page=com.atlassian.jira.plugin.... ]
Mustafa Musaji updated WFLY-4487:
---------------------------------
Attachment: cdi-interceptors.zip
Added reproducer
> Unable to inject Web Service Context into CDI Interceptor
> ---------------------------------------------------------
>
> Key: WFLY-4487
> URL: https://issues.jboss.org/browse/WFLY-4487
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 9.0.0.Alpha1
> Reporter: Mustafa Musaji
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
> Attachments: cdi-interceptors.zip
>
>
> CDI Interceptor cannot inject Web Service context.
> When trying to inject WebServiceContext in CDI Interceptor using @Resource annotation but it fails with: NameNotFoundException: env/org.example.MyInterceptor/webServiceContext
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4487) Unable to inject Web Service Context into CDI Interceptor
by Mustafa Musaji (JIRA)
[ https://issues.jboss.org/browse/WFLY-4487?page=com.atlassian.jira.plugin.... ]
Mustafa Musaji updated WFLY-4487:
---------------------------------
Description:
CDI Interceptor cannot inject Web Service context.
When trying to inject WebServiceContext in CDI Interceptor using @Resource annotation but it fails with: NameNotFoundException: env/org.example.MyInterceptor/webServiceContext
> Unable to inject Web Service Context into CDI Interceptor
> ---------------------------------------------------------
>
> Key: WFLY-4487
> URL: https://issues.jboss.org/browse/WFLY-4487
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 9.0.0.Alpha1
> Reporter: Mustafa Musaji
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
> Attachments: cdi-interceptors.zip
>
>
> CDI Interceptor cannot inject Web Service context.
> When trying to inject WebServiceContext in CDI Interceptor using @Resource annotation but it fails with: NameNotFoundException: env/org.example.MyInterceptor/webServiceContext
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4487) Unable to inject Web Service Context into CDI Interceptor
by Mustafa Musaji (JIRA)
[ https://issues.jboss.org/browse/WFLY-4487?page=com.atlassian.jira.plugin.... ]
Mustafa Musaji updated WFLY-4487:
---------------------------------
Description: (was: CDI Interceptor cannot inject EJB session context.
If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject.
See attached reproducer with source and log file.
private @Resource SessionContext sessionContext;
Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185)
... 127 more
)
Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6759, https://github.com/wildfly/wildfly/pull/6893)
> Unable to inject Web Service Context into CDI Interceptor
> ---------------------------------------------------------
>
> Key: WFLY-4487
> URL: https://issues.jboss.org/browse/WFLY-4487
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 9.0.0.Alpha1
> Reporter: Mustafa Musaji
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4487) Unable to inject Web Service Context into CDI Interceptor
by Mustafa Musaji (JIRA)
Mustafa Musaji created WFLY-4487:
------------------------------------
Summary: Unable to inject Web Service Context into CDI Interceptor
Key: WFLY-4487
URL: https://issues.jboss.org/browse/WFLY-4487
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 9.0.0.Alpha1
Reporter: Mustafa Musaji
Assignee: Stuart Douglas
Fix For: 9.0.0.Beta1
CDI Interceptor cannot inject EJB session context.
If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject.
See attached reproducer with source and log file.
private @Resource SessionContext sessionContext;
Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185)
... 127 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4423) ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4423?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4423:
-----------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1201358|https://bugzilla.redhat.com/show_bug.cgi?id=1201358] from NEW to POST
> ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory
> ----------------------------------------------------------------------------
>
> Key: WFLY-4423
> URL: https://issues.jboss.org/browse/WFLY-4423
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 9.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Beta1
>
>
> To reproduce this issue follow the steps:
> - setup JMS bridge between two WildFly instances
> - once JMS bridge is running, login into jboss-cli and stop the bridge
> - restart the bridge fro jboss-cli
> The following exception appears in the serve log file.
> 10:12:59,414 INFO [org.hornetq.jms.server] (pool-9-thread-1) HQ121000: Failed to set up JMS bridge connections. Most probably the source or target servers are unavailable. Will retry after a pause of 60,000 ms
> 10:13:59,416 WARN [org.hornetq.jms.server] (pool-9-thread-1) HQ122010: Failed to connect JMS Bridge: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.naming.remote.client.InitialContextFactory from classloader ModuleClassLoader for Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:126)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:107)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_75]
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:98)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_75]
> at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55)
> at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1236)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1474)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$2200(JMSBridgeImpl.java:79)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:2082)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> Caused by: java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_75]
> at java.lang.Class.forName(Class.java:274) [rt.jar:1.7.0_75]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:121)
> ... 17 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (SECURITY-878) Container-provided security role "**" (EJB 3.2) not working
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/SECURITY-878?page=com.atlassian.jira.plug... ]
Stuart Douglas reassigned SECURITY-878:
---------------------------------------
Assignee: Stefan Guilhen (was: Stuart Douglas)
EJB authentication support is now provided by PicketBox, it is not actually part of the Wildfly code base.
> Container-provided security role "**" (EJB 3.2) not working
> -----------------------------------------------------------
>
> Key: SECURITY-878
> URL: https://issues.jboss.org/browse/SECURITY-878
> Project: PicketBox
> Issue Type: Bug
> Affects Versions: PicketBox_4_0_21.Final
> Reporter: Jan Martiska
> Assignee: Stefan Guilhen
>
> EJB 3.2 12.3.1 Security Roles:
> {quote}
> A security role with the name “**” is defined by the Container, and is intended to be used by the Bean
> Provider, Application Assembler, or Deployer to indicate that the caller must log on or authenticate to
> invoke a method or to perform some processing requiring membership in this container role. This con-
> tainer security role indicates that authentication, without consideration of role membership, is required.
> {quote}
> This doesn't seem to work in WildFly 9.0.0.Beta1. An authenticated user trying to invoke methods annotated @PermitAll("**") gets an EJBAccessException.
> I started preparing tests for this behavior at https://github.com/jmartisk/wildfly/commits/master-ejb32tests-starrole
> It causes failures in:
> InherritanceAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> InherritanceAnnSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSLSBTestCase.testSingleMethodAnnotationsUser1
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (SECURITY-878) Container-provided security role "**" (EJB 3.2) not working
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/SECURITY-878?page=com.atlassian.jira.plug... ]
Stuart Douglas moved WFLY-4474 to SECURITY-878:
-----------------------------------------------
Project: PicketBox (was: WildFly)
Key: SECURITY-878 (was: WFLY-4474)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Affects Version/s: PicketBox_4_0_21.Final
(was: 9.0.0.Beta1)
> Container-provided security role "**" (EJB 3.2) not working
> -----------------------------------------------------------
>
> Key: SECURITY-878
> URL: https://issues.jboss.org/browse/SECURITY-878
> Project: PicketBox
> Issue Type: Bug
> Affects Versions: PicketBox_4_0_21.Final
> Reporter: Jan Martiska
> Assignee: Stuart Douglas
>
> EJB 3.2 12.3.1 Security Roles:
> {quote}
> A security role with the name “**” is defined by the Container, and is intended to be used by the Bean
> Provider, Application Assembler, or Deployer to indicate that the caller must log on or authenticate to
> invoke a method or to perform some processing requiring membership in this container role. This con-
> tainer security role indicates that authentication, without consideration of role membership, is required.
> {quote}
> This doesn't seem to work in WildFly 9.0.0.Beta1. An authenticated user trying to invoke methods annotated @PermitAll("**") gets an EJBAccessException.
> I started preparing tests for this behavior at https://github.com/jmartisk/wildfly/commits/master-ejb32tests-starrole
> It causes failures in:
> InherritanceAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> InherritanceAnnSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSLSBTestCase.testSingleMethodAnnotationsUser1
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month