Re: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing

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/... > >> > > >> > 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/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 > >> >> > >> >> > > > > >