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

[Sanne Grinovero]

On 7 September 2017 at 22:38, Gail Badner <gbadner at redhat.com> 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 at hibernate.org>
> 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 at hibernate.org> 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 at 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 <steve at 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 <sanne at 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 <gbadner at 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
>> >>>> > <sanne at 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 at lists.jboss.org
>> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>> >
>> >>>> >
>> >>>> _______________________________________________
>> >>>> hibernate-dev mailing list
>> >>>> hibernate-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >>
>
>