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
