2:11 p.m.
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/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(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-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/
> ExtendedBeanManagerCdiTest.java#L195
> >
> > 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
>