[hibernate-dev] CDI / ORM / WildFly / Search integration plumbing
Steve Ebersole
steve at hibernate.org
Thu Sep 7 19:28:34 EDT 2017
My suggestion to Sanne (not sure if he was going to take this approach) was
to essentially copy the way I handle this in 6 :
https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/resource/cdi/spi/ManagedBeanRegistry.java
On Thu, Sep 7, 2017, 5:38 PM Gail Badner <gbadner at redhat.com> wrote:
> 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 at hibernate.org>
> wrote:
>
>> 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
>> >> >>
>> >> >>
>> >
>> >
>>
>
>
More information about the hibernate-dev
mailing list