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

Sanne Grinovero sanne at hibernate.org
Thu Sep 7 13:36:31 EDT 2017


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


More information about the hibernate-dev mailing list