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