Re: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing
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