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

[Gail Badner]

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