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

[Scott Marlow]

On 08/30/2017 11:27 AM, Sanne Grinovero 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.

Could you test if the beanManager is an instance of 
org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager and if yes, wait 
until after the 
org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager.beanManagerInitialized(javax.enterprise.inject.spi.BeanManager) 
has been called, to use the real bean manager?

Prior to the ExtendedBeanManager.beanManagerInitialized(), there is no 
BeanManager available, so we really need to defer finishing any parts of 
deployment, that need a bean manager, until that fires.

I'm not sure though, how you will get the real underlying bean manager, 
perhaps you need to integrate with the 
org.hibernate.jpa.event.internal.jpa.ListenerFactoryBeanManagerExtendedImpl 
or something like that.

Also, you shouldn't expect to always be passed an ExtendedBeanManager, 
as you want to still work when beanManager is actually a 
javax.enterprise.inject.spi.BeanManager.

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