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(a)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(a)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/...
> >
> > 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(a)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(a)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(a)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/ja...
> >>>>
> >>>> 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(a)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-entitymanag...
> >>>> >
> >>>> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero
> >>>> > <sanne(a)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(a)lists.jboss.org
> >>>> >>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>> >
> >>>> >
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev(a)lists.jboss.org
> >>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>