On Tue, Jan 2, 2018 at 2:42 PM, Steve Ebersole <st...@hibernate.org> wrote:
> Scott, how would we register a listener for this event? > If we want a standard solution, we could ask for an earlier CDI pre-destroy listener. The problem we have had with most CDI "listeners" so far is that they are > non-contextual, meaning there has been no way to link that back to a > specific SessionFactory.. If I can register this listener with a reference > back to the Sessionfactory, this should actually be fine. > I could pass the EMF to the org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager.LifecycleListener, if that helps. > > On Tue, Jan 2, 2018 at 1:39 PM Scott Marlow <smar...@redhat.com> wrote: > >> On Wed, Dec 20, 2017 at 9:48 AM, Sanne Grinovero <sa...@hibernate.org> >> wrote: >> >> > Any dependency injection framework will have some capability to define >> > the graph of dependencies across components, and such graph could be >> > very complex, with details only known to the framework. >> > >> > I don't think we can solve the integration by having "before all >> > others" / "after all others" phases as that's too coarse grained to >> > define a full graph; we need to find a way to have the DI framework >> > take in consideration our additional components both in terms of DI >> > consumers and providers - then let the framework wire up things in the >> > order it prefers. This is also to allow the DI engine to print >> > appropriate warnings for un-resolvable situations with its native >> > error handling, which would resolve in more familiar error messages. >> > >> > If that's not doable *or a priority* then all we can do is try to make >> > it clear enough that there will be limitations and hopefully describe >> > these clearly. Some of such limitations might be puzzling as you >> > describe. >> > >> > >> > >> > On 20 December 2017 at 12:50, Yoann Rodiere <yo...@hibernate.org> >> wrote: >> > > Hello all, >> > > >> > > TL;DR: Application-scoped beans cannot be used as part of the >> @PreDestroy >> > > method of ORM-instantiated CDI beans, and it's a bit odd because they >> can >> > > be used as part of the @PostConstruct method. >> > > >> > > I've been testing the CDI integration in Hibernate ORM for the past >> few >> > > days, trying to integrate it into Search. I think I've discovered >> > something >> > > odd: when CDI-managed beans are destroyed, they cannot access other >> > > Application-scoped CDI beans anymore. Not sure whether this is a >> problem >> > or >> > > not, so maybe we should discuss it a bit before going forward with the >> > > current behavior. >> > > >> > > Short reminder: scopes define when CDI beans are created and >> destroyed. >> > > @ApplicationScoped is pretty self-explanatory: created when the >> > application >> > > starts and destroyed when it stops. Some other scopes are a bit more >> > > convoluted: @Singleton basically means created *before* the >> application >> > > starts and destroyed *after* the application stops (and also means >> "this >> > > bean shall not be proxied"), @Dependent means created when an >> instance is >> > > requested and destroyed when the instance is released, etc. >> > > >> > > The thing is, Hibernate ORM is typically started very early and shut >> down >> > > very late in the CDI lifecycle - at least within WildFly. So when >> > Hibernate >> > > starts, CDI Application-scoped beans haven't been instantiated yet, >> and >> > it >> > > turns out that when Hibernate ORM shuts down, CDI has already >> destroyed >> > > Application-scoped beans. >> > > >> > > Regarding startup, Steve and Scott solved the problem by delaying bean >> > > instantiation to some point in the future when the Application scope >> is >> > > active (and thus Application-scoped beans are available). This makes >> it >> > > possible to use Application-scoped beans within ORM-instantiated >> beans as >> > > soon as the latter are constructed (i.e. within their @PostConstruct >> > > methods). >> > > However, when Hibernate ORM shuts down, the Application scope has >> already >> > > been terminated. So when ORM destroys the beans it instantiated, those >> > > ORM-instantiated beans cannot call a method on referenced >> > > Application-scoped beans (CDI proxies will throw an exception). >> > > >> > > All in all, the only type of beans we can currently use in a >> @PreDestroy >> > > method of an ORM-instantiated bean is @Dependent beans. @Singleton >> beans >> > > will work, but only because they are not proxied and thus you can >> cheat >> > and >> > > use them even after they have been destroyed... which I definitely >> > wouldn't >> > > recommend. >> > > >> > > I see two ways to handle the issue: >> > > >> > > 1. We don't change anything, and simply document somewhere that >> beans >> > > instantiated as part of the CDI integration are instantiated within >> > the >> > > Application scope, but are destroyed outside of it. And we suggest >> > that any >> > > bean used in @PostDestroy method in an ORM-instantiated bean >> > (directly or >> > > not) must have either a @Dependent scope, or a @Singleton scope >> and no >> > > @PostDestroy method. >> > > 2. We implement an "early shut-down" somehow, which would bring >> > forward >> > > bean destruction to some time when the Application scope is still >> > active. >> > >> >> org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager mentions that we >> could >> look at introducing a beanManagerDestroyed notification, if that is useful >> and we can find a way to implement it (javax.enterprise.spi. >> BeforeShutdown >> [1] is not early enough to meet your requirements). >> >> Scott >> >> [1] >> https://docs.oracle.com/javaee/7/api/javax/enterprise/ >> inject/spi/BeforeShutdown.html >> >> >> > > >> > > #1 may be enough for now, even though the behavior feels a bit odd, >> and >> > > forces users to resort to less-than-ideal practices (using a >> @Singleton >> > > bean after it has been destroyed). >> > > >> > > #2 would require changes in WildFly and may be a bit complex. In >> > > particular, if we aren't careful, Application-scoped beans may not be >> > able >> > > to use Hibernate ORM from within their @PreDestroy methods... Which is >> > > probably not a good idea. So we would have to find a solution together >> > with >> > > the WildFly team. Also to be considered: Hibernate Search would have >> to >> > be >> > > shut down just before the "early shut-down" of Hibernate ORM occurs, >> > > because Hibernate Search cannot function at all without the beans it >> > > retrieves from the CDI context. >> > > >> > > Thoughts? >> > > >> > > >> > > Yoann Rodière >> > > Hibernate NoORM Team >> > > yo...@hibernate.org >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev@lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
