[jboss-jira] [JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing

[John Ament (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164321#comment-13164321 ] 

John Ament commented on WFLY-2387:
----------------------------------

The impression that I have from looking through this ticket, as well as the relevant HHH tickets, is that the assumption is that an entity listener is booted on start up of the persistence unit.  While this is probably true of a non-CDI managed one, I would expect the entity listener to be looked up when needed to perform an operation instead of eagerly being initialized.  This is the part where I think scoping may have some kind of impact.

Suppose I have

@RequestScoped
public class MyListener implements EntityListener { .. }

I would expect that this listener is used whenever needed within a single HTTP request.  I think (and I haven't tested this yet) that instead a more global listener is used, probably created during app start up.  Maybe I'm making a wild assumption, that's why I'm bringing it up to see what you think.

Granted, the JPA spec doesn't use the term contextual reference, so I'm not sure if I'm reading too much between the lines either.

How does this relate to this ticket?  Well, these are two points.  Probably the third is that if I'm starting up an application, I have various scopes active during start up.  I might be doing work with JPA before CDI is fully loaded.  The only valid places to do stuff like this is in AfterDeploymentValidation, the PostConstruct methods on app scoped beans, and observers for initialized application scoped events.  In all of those cases, CDI should be fully running and JPA could in theory wait until that point to get its references to an entity listener needed for those operations, assuming there are no cyclic dependencies.

> CDI injection in entity listeners failing
> -----------------------------------------
>
>                 Key: WFLY-2387
>                 URL: https://issues.jboss.org/browse/WFLY-2387
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, Class Loading, JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emond Papegaaij
>            Assignee: Scott Marlow
>         Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> 	at org.jboss.weld.Container.instance(Container.java:65)
> 	at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> 	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> 	at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> 	... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)