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-entitymanag... On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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/ja... 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 <gbadner(a)redhat.com&gt; 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-entitymanag... > > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; > 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 <steve(a)hibernate.org&gt; 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 <sanne(a)hibernate.org&gt; > 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/ja... >> >> 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 <gbadner(a)redhat.com&gt; 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-entitymanag... >> > >> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; >> > 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(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev

I had a chat with Steve about this and I understand better now why the WildFly/JipiJapa/HibernateORM does what it does. We'll update the Hibernate Search integration test and move on! Thanks, Sanne On 6 September 2017 at 22:19, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > 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 <gbadner(a)redhat.com&gt; 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 <steve(a)hibernate.org&gt; >> 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 <sanne(a)hibernate.org&gt; >>> 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 <gbadner(a)redhat.com&gt; 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 < sanne(a)hibernate.org&gt; >>>> > 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(a)lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>

On 7 September 2017 at 22:38, Gail Badner <gbadner(a)redhat.com&gt; wrote: > Are you saying that you don't need a fix for this? I'm going to need fixing the Hibernate Search code, but besides that yes I'm not needing (nor expecting) a fix in either WildFly (jipijapa) nor Hibernate ORM. Thanks, Sanne > > On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: >> >> I had a chat with Steve about this and I understand better now why the >> WildFly/JipiJapa/HibernateORM does what it does. >> >> We'll update the Hibernate Search integration test and move on! >> >> Thanks, >> Sanne >> >> >> On 6 September 2017 at 22:19, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: >> > 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 <gbadner(a)redhat.com&gt; 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 < steve(a)hibernate.org&gt; >> >> 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 < sanne(a)hibernate.org&gt; >> >>> 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 <gbadner(a)redhat.com&gt; 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 >> >>>> > <sanne(a)hibernate.org&gt; >> >>>> > 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(a)lists.jboss.org >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>>> > >> >>>> > >> >>>> _______________________________________________ >> >>>> hibernate-dev mailing list >> >>>> hibernate-dev(a)lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> > >

My suggestion to Sanne (not sure if he was going to take this approach) was to essentially copy the way I handle this in 6 : https://github.com/sebersole/hibernate-core/blob/wip/6.0/ hibernate-core/src/main/java/org/hibernate/resource/cdi/ spi/ManagedBeanRegistry.java On Thu, Sep 7, 2017, 5:38 PM Gail Badner <gbadner(a)redhat.com&gt; wrote: > OK, sounds good. Did Steve suggest how to fix it in HSearch? If he > didn't, I have kind of a hacky idea. > > On Thu, Sep 7, 2017 at 2:59 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: > >> On 7 September 2017 at 22:38, Gail Badner <gbadner(a)redhat.com&gt; wrote: >> > Are you saying that you don't need a fix for this? >> >> I'm going to need fixing the Hibernate Search code, but besides that >> yes I'm not needing (nor expecting) a fix in either WildFly (jipijapa) >> nor Hibernate ORM. >> >> Thanks, >> Sanne >> >> > >> > On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; >> > wrote: >> >> >> >> I had a chat with Steve about this and I understand better now why the >> >> WildFly/JipiJapa/HibernateORM does what it does. >> >> >> >> We'll update the Hibernate Search integration test and move on! >> >> >> >> Thanks, >> >> Sanne >> >> >> >> >> >> On 6 September 2017 at 22:19, Sanne Grinovero <sanne(a)hibernate.org&gt; >> wrote: >> >> > 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 <gbadner(a)redhat.com&gt; >> 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 < >> steve(a)hibernate.org&gt; >> >> >> 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 < >> sanne(a)hibernate.org&gt; >> >> >>> 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 <gbadner(a)redhat.com&gt; >> 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 >> >> >>>> > <sanne(a)hibernate.org&gt; >> >> >>>> > 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(a)lists.jboss.org >> >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >>>> > >> >> >>>> > >> >> >>>> _______________________________________________ >> >> >>>> hibernate-dev mailing list >> >> >>>> hibernate-dev(a)lists.jboss.org >> >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> >> >> > >> > >> > >