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