Hi Gail, the failing test is CDIInjectionIT from my personal branch of Hibernate Search called "WildFly11" :
https://github.com/Sanne/hibernate-search/blob/WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/integration/wildfly/cdi/CDIInjectionIT.java It is an Arquillian test and it requires you to build Hibernate ORM master first, as I switched the dependencies to use Hibernate ORM 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires HHH-11950 Thanks, Sanne On 1 September 2017 at 19:11, Gail Badner <gbad...@redhat.com> wrote: > 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