Well there seems to be some disagreement about that. I personally think we do not need anything other than a pre-shutdown hook so that we can release our CDI references. Sanne seemed to think we needed something more "integrated". I think we should start with the simple and add deeper integration (which requires actual CDI changes) only if we see that is necessary. Sanne?
On Thu, Jan 4, 2018 at 7:58 AM Scott Marlow <smar...@redhat.com> wrote: > I can arrange to keep access to the specific > ExtendedBeanManager/LifecycleListener, that is not difficult. > > What changes do we need from the CDI implementation? > > > On Jan 3, 2018 4:36 PM, "Steve Ebersole" <st...@hibernate.org> wrote: > > If you have access to the specific ExtendedBeanManager/LifecycleListener, > that should already be enough. Those things are already properly scoped to > the SessionFactory, unless you are passing the same instance to multiple > SessionFactory instances. > > On Wed, Jan 3, 2018 at 10:09 AM Scott Marlow <smar...@redhat.com> wrote: > >> 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