[JBoss JIRA] (WFLY-7278) Elytron LdapKeyStore - classloading of LdapCtxFactory
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7278:
-----------------------------
Description:
When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
{code:java}
Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.init(InitialContext.java:244)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
... 16 more
java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
... 28 more
{code}
was:
When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
{code:java}
java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
... 28 more
{code}
> Elytron LdapKeyStore - classloading of LdapCtxFactory
> -----------------------------------------------------
>
> Key: WFLY-7278
> URL: https://issues.jboss.org/browse/WFLY-7278
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> ... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> ... 28 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-7278) Elytron LdapKeyStore - classloading of LdapCtxFactory
by Jan Kalina (JIRA)
Jan Kalina created WFLY-7278:
--------------------------------
Summary: Elytron LdapKeyStore - classloading of LdapCtxFactory
Key: WFLY-7278
URL: https://issues.jboss.org/browse/WFLY-7278
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Jan Kalina
Assignee: Jan Kalina
When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
{code:java}
java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
... 28 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (JGRP-2110) Transport: revisit buffers and threading
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2110?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2110:
--------------------------------
http://ithare.com/network-programming-socket-peculiarities-threads-and-te...
> Transport: revisit buffers and threading
> ----------------------------------------
>
> Key: JGRP-2110
> URL: https://issues.jboss.org/browse/JGRP-2110
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> (Concerns only the receiver side)
> h4. Parsing
> Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only receive fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
> This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
> h4. Buffers
> * UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
> * TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
> * TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
> h4. Approaches
> # The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
> # The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
> # UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
> # To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
> h4. Goals
> Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (JGRP-2110) Transport: revisit buffers and threading
by Bela Ban (JIRA)
Bela Ban created JGRP-2110:
------------------------------
Summary: Transport: revisit buffers and threading
Key: JGRP-2110
URL: https://issues.jboss.org/browse/JGRP-2110
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0
(Concerns only the receiver side)
h4. Parsing
Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only receive fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
h4. Buffers
* UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
* TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
* TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
h4. Approaches
# The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
# The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
# UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
# To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
h4. Goals
Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-7277) NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-7277:
------------------------------------
Summary: NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
Key: WFLY-7277
URL: https://issues.jboss.org/browse/WFLY-7277
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.0.0.Final, 10.1.0.Final
Environment: Win7 64bit + JDK8 64bit
Reporter: Darryl Miles
Assignee: Stuart Douglas
1 in 8 deployments fail to deploy, usually a redeploy fixes it.
If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails. I guess there is a race bug there somewhere.
09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
... 6 more
Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
... 11 more
Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
... 26 more
Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
... 43 more
Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
... 48 more
Caused by: java.lang.NullPointerException
at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
... 49 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6663) NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-6663:
------------------------------------
Assignee: Stuart Douglas
> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6663
> URL: https://issues.jboss.org/browse/WFLY-6663
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Win7 64bit + JDK8 64bit
> Reporter: Darryl Miles
> Assignee: Stuart Douglas
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails. I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 48 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> ... 49 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6585) IIOP bean lookup fails after transaction timeout happens
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6585?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski closed WFLY-6585.
--------------------------------
Resolution: Done
> IIOP bean lookup fails after transaction timeout happens
> --------------------------------------------------------
>
> Key: WFLY-6585
> URL: https://issues.jboss.org/browse/WFLY-6585
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 10.0.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
>
> IIOP lookup call for a bean could fails when transaction timeout happens on the lookuped bean. The exception is {{javax.naming.NameNotFoundException: null}} [1]
> My feeling is that the issue has something to do with transaction timeout when JTS/iiop lookup is used. My experience is that the same type of testcase passes when JTA/ejb remoting is used.
> What I can say I think that lookup fails on server at time when 'get_txcontext' is used. I mean that is what could be seen from server.log file [2] (attached).
> [1]
> {code}
> javax.naming.NameNotFoundException: null
> at org.omg.CosNaming.NamingContextPackage.NotFoundHelper.read(NotFoundHelper.java:72)
> at org.omg.CosNaming._NamingContextStub.resolve(_NamingContextStub.java:251)
> at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:486)
> at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:539)
> at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:517)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.as.test.integration.transactions.TransactionTestLookupUtil.lookupIIOP(TransactionTestLookupUtil.java:77)
> at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.lookupStateful(IIOPTimeoutTestCase.java:176)
> at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful(IIOPTimeoutTestCase.java:157)
> {code}
> [2]
> 2016-04-27 19:38:09,297 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionClientRequestInterceptorImpl::send_request ( get_txcontext ) nodeId=1 requestId=64
> 2016-04-27 19:38:09,297 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( get_txcontext ) nodeId=1 requestId=70
> 2016-04-27 19:38:09,297 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) Intercepting receive_request_service_contexts, operation: get_txcontext
> 2016-04-27 19:38:09,300 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) send_exception: get_txcontext
> 2016-04-27 19:38:09,300 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::send_exception ( get_txcontext ) nodeId=1 requestId=70
> 2016-04-27 19:38:09,300 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::suspendContext ( get_txcontext ) nodeId=1 requestId=70
> 2016-04-27 19:38:09,303 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionClientRequestInterceptorImpl::receive_exception ( get_txcontext ) nodeId=1 requestId=64
> 2016-04-27 19:38:09,305 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) send_exception: resolve
> 2016-04-27 19:38:09,305 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::send_exception ( resolve ) nodeId=1 requestId=69
> 2016-04-27 19:38:09,305 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::suspendContext ( resolve ) nodeId=1 requestId=69
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6663) NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.... ]
jaikiran pai edited comment on WFLY-6663 at 10/8/16 11:34 AM:
--------------------------------------------------------------
I see what's going on (and am able to reproduce it within the WildFly testsuite). It isn't related to anything transaction management. The root cause of the issue is that the startup singleton bean injects a *remote view of a stateful session bean*. Internally, when the injection process on that singleton startup bean is in progress, it triggers a session creation on the stateful session bean, even before the (MSC service backing the) stateful component has started.
The relevant piece of code in WildFly is (I think) this https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... where it skips adding a dependency and instead sets up the RemoteViewManagedReferenceFactory which later on just goes ahead and tries to create a component session for the stateful bean https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
I have been away from WildFly code for a while now and can't think of a way to fix this properly, given that ejb: lookups in theory don't need to depend on the component, if the component is really "remote" and doesn't reside on the same server, which is not the case in the example above. Someone else in the WildFly dev team, I believe, will be able to fix this properly.
The only workaround that I can think of is, if your MainEjb which I believe is a stateful bean has a local business interface too, then use that interface for injection instead of the remove business interface here:
{code}
@EJB
private MainEjb mainEjb; // use a local business interface instead of a remote one
{code}
was (Author: jaikiran):
I see what's going on (and am able to reproduce it within the WildFly testsuite). It isn't related to anything transaction management. The root cause of the issue is that the startup singleton bean injects a *remote view of a stateful session bean*. Internally, when the injection process on that singleton startup bean is in progress, it triggers a session creation on the stateful session bean, even before the (MSC service backing the) stateful component has started.
The relevant piece of code in WildFly is (I think) this https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... where it skips adding a dependency and instead sets up the RemoteViewManagedReferenceFactory which later on just goes ahead and tries to create a component session for the stateful bean https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
I have been away from WildFly code for a while now and can't think of a way to fix this properly, given that ejb: lookups in theory don't need to depend on the component, if the component is really "remote" and doesn't reside on the same server, which is not the case in the example above. Someone else in the WildFly dev team, I believe, will be able to fix this properly.
The only workaround that I can think of is, if you MainEjb which I believe is a stateful bean has a local business interface too, then use that interface for injection instead of the remove business interface here:
{code}
@EJB
private MainEjb mainEjb; // use a local business interface instead of a remote one
{code}
> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6663
> URL: https://issues.jboss.org/browse/WFLY-6663
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Win7 64bit + JDK8 64bit
> Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails. I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 48 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> ... 49 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months