I have a better understanding after discussing further with Scott, so I agree with Steve now.
I have some ideas about how to fix this. Sanne, you mentioned getting a failure using an integration test. Please provide details for reproducing this. On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole <st...@hibernate.org> wrote: > The whole purpose of ExtendedBeanManager is cases where the BeanManager is > not available when Hibernate boots (in other words when Hibernate is told > which to use) . This is a way to give Hibernate a callback when the > BeanManager is available. IMO this ExtendedBeanManager implementing > BeanManager is inaccurate. But would certainly like to hear Scott's > opinion as well. > > Technically this situation is non-JPA compliant as JPA requires that the > BeanManager passed to be available at boot-time. > > On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero <sa...@hibernate.org> > wrote: > >> Hi Gail, >> >> no I haven't opened a WFLY issue as I'm not sure if this is an issue. >> >> There seems to be some inconsistency and it certainly breaks some >> Hibernate Search tests but we could of course adapt things to the new >> reality.. if this is how it's meant to be. >> >> The source code of the ExtendedBeanManager which you didn't find is >> located in the WildFly source code; it's part of JipiJapa: >> - https://github.com/wildfly/wildfly/blob/master/jpa/ >> hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/ >> HibernateExtendedBeanManager.java >> >> As you also noticed, it no longer implement the standard BeanManager >> interface. I agree with you that I'd expect it to still implement it, >> but clearly this was changed intentionally so I hope someone (Scott >> possibly?) can clarify - or revert. >> >> In case this is intentionally no longer implementing the standard >> interface we should at least clarify the javadocs if this >> configuration property. >> >> The missing javax.el.ELResolver and javax.el.ExpressionFactory is >> unfortunate. I'd hope we could do better than just add them back, >> maybe it requires a dedicated module? Having too many dependencies - >> in this case half of Weld - slows down our bootstrap significantly and >> users have been complaining about that. >> >> Thanks, >> Sanne >> >> On 30 August 2017 at 06:58, Gail Badner <gbad...@redhat.com> wrote: >> > Hi Sanne, >> > >> > Do you have a WFLY issue for this? >> > >> > I've tentatively created a branch and pushed a commit to my fork that >> > reproduces this issue. [1] >> > >> > It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT. >> > >> > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses an >> > implementation, ExtendedBeanManagerImpl [2], that implements both >> > BeanManager, ExtendedBeanManager. >> > >> > I don't see this test in 5.2, and I don't see any implementation of >> > ExtendedBeanManager in 5.2. I do see tests in >> > org.hibernate.jpa.test.cdi.extended, but have not had a chance to look >> at >> > those yet. >> > >> > I suspect that org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager >> > should implement javax.enterprise.inject.spi.BeanManager as well. I >> tried >> > making this change, and having BeanManager methods delegate to >> > HibernateExtendedBeanManager#beanManager, but it looks like a >> dependency is >> > missing, because javax.el.ELResolver and javax.el.ExpressionFactory are >> > unresolved. >> > >> > Please let me know if I'm on the right (or wrong) track. I'll pick this >> up >> > tomorrow. >> > >> > Regards, >> > Gail >> > >> > [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug >> > [2] >> > https://github.com/hibernate/hibernate-orm/blob/5.1/ >> hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ >> ExtendedBeanManagerCdiTest.java#L195 >> > >> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero <sa...@hibernate.org> >> > wrote: >> >> >> >> Hi all, >> >> >> >> In Hibernate Search we have a snippet of code doing: >> >> >> >> private static BeanManager getBeanManager(Map<?, ?> >> configurationValues) { >> >> return (BeanManager) configurationValues.get( >> >> AvailableSettings.CDI_BEAN_MANAGER ); >> >> } >> >> >> >> This used to work on WildFly 10 - even if we were to override the >> >> Hibernate ORM version to 5.2. >> >> >> >> By runnning the same integration test on WildFly 11 I'm now getting a >> >> ClassCastException as the returned instance is of type >> >> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which does >> >> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` but >> >> does not implement the standard >> >> `javax.enterprise.inject.spi.BeanManager` interface. >> >> >> >> I'm unsure if this is a bug in the Search code or a misunderstanding >> >> between the WildFly / ORM integration? >> >> >> >> This javadoc seems relevant: >> >> >> >> /** >> >> * Used to pass along the CDI BeanManager, if any, to be used. >> >> */ >> >> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager"; >> >> >> >> or should I interpret this property as meant only for "write" purposes >> >> into the ORM configuration? I suppose it's unexpected that we attempt >> >> to retrieve this as well. >> >> >> >> Thanks, >> >> Sanne >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev@lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
