Re: [hibernate-dev] ORM & Java 9 - strange javadoc failure
Steve, there is a reference to org.hibernate.engine.Mapping in a
non-javadoc comment with a javadoc tag
("@see"): org.hibernate.spatial.dialect.oracle.SDOObjectProperty#getReturnType
Also: org.hibernate.spatial.dialect.oracle.SDOObjectMethod#getReturnType
Maybe you could try removing/fixing this comment and see how it goes? The
bug may be about the javadoc processor trying to process non-javadoc
comments whenever it sees a javadoc tag... Which could be worked around
easily.
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 2 January 2018 at 20:15, Steve Ebersole wrote:
> Sanne, have you had a chance to look at this? If not, I may have to just
> disable Java 9 from Travis
>
> On Wed, Dec 27, 2017 at 8:37 PM Steve Ebersole
> wrote:
>
> > I worked on getting Travis CI set up on ORM for reasons discussed here
> > previously. But I am running into a really strange error when I enabled
> > Java 9:
> >
> > javadoc: error - An exception occurred while building a component:
> > ClassSerializedForm
> > (com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
> > org.hibernate.engine.Mapping not found)
> > Please file a bug against the javadoc tool via the Java bug reporting
> page
> > (http://bugreport.java.com) after checking the Bug Database (
> > http://bugs.java.com)
> > for duplicates. Include error messages and the following diagnostic in
> > your report. Thank you.
> > com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
> > org.hibernate.engine.Mapping not found
> >
> > It seems like javadoc is complaining because it sees a reference to a
> > class (org.hibernate.engine.Mapping) that it cannot find. It is true
> that
> > there is no class named org.hibernate.engine.Mapping, the real name is
> > org.hibernate.engine.spi.Mapping - but what is strange is that I search
> the
> > entire ORM project and found zero references to the String
> > org.hibernate.engine.Mapping.
> >
> > I just kicked off a run of the ORM / Java 9 Jenkins job to see if it has
> > the same failure.
> >
> > Anyone have any ideas?
> >
> >
> ___
> 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] Repository renamed: lucene-modules -> lucene-jbossmodules
Hi all, we renamed the Git repository name, and the respective GitHub project, from lucene-modules to lucene-jbossmodules. Obviously "modules" alone was getting a bit too ambiguous. We decided to not call them "WildFly modules" as these are not used only for WildFly, and the modular technology is called "JBoss Modules" [1]. Please don't forget to update your references in any git clone you might have! Thanks, Sanne 1- https://jboss-modules.github.io/jboss-modules/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] ORM & Java 9 - strange javadoc failure
Here is the version that triggered the Travis job:
https://github.com/sebersole/hibernate-core/blob/5.3/hibernate-spatial/src/main/java/org/hibernate/spatial/dialect/oracle/SDOObjectMethod.java
As you can see those (non-)references are removed. Same error.
On Wed, Jan 3, 2018 at 3:32 AM Yoann Rodiere wrote:
> Steve, there is a reference to org.hibernate.engine.Mapping in a
> non-javadoc comment with a javadoc tag
> ("@see"): org.hibernate.spatial.dialect.oracle.SDOObjectProperty#getReturnType
> Also: org.hibernate.spatial.dialect.oracle.SDOObjectMethod#getReturnType
> Maybe you could try removing/fixing this comment and see how it goes? The
> bug may be about the javadoc processor trying to process non-javadoc
> comments whenever it sees a javadoc tag... Which could be worked around
> easily.
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
> On 2 January 2018 at 20:15, Steve Ebersole wrote:
>
>> Sanne, have you had a chance to look at this? If not, I may have to just
>> disable Java 9 from Travis
>>
>
>> On Wed, Dec 27, 2017 at 8:37 PM Steve Ebersole
>> wrote:
>>
>> > I worked on getting Travis CI set up on ORM for reasons discussed here
>> > previously. But I am running into a really strange error when I enabled
>> > Java 9:
>> >
>> > javadoc: error - An exception occurred while building a component:
>> > ClassSerializedForm
>> > (com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
>> > org.hibernate.engine.Mapping not found)
>> > Please file a bug against the javadoc tool via the Java bug reporting
>> page
>> > (http://bugreport.java.com) after checking the Bug Database (
>> > http://bugs.java.com)
>> > for duplicates. Include error messages and the following diagnostic in
>> > your report. Thank you.
>> > com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
>> > org.hibernate.engine.Mapping not found
>> >
>> > It seems like javadoc is complaining because it sees a reference to a
>> > class (org.hibernate.engine.Mapping) that it cannot find. It is true
>> that
>> > there is no class named org.hibernate.engine.Mapping, the real name is
>> > org.hibernate.engine.spi.Mapping - but what is strange is that I search
>> the
>> > entire ORM project and found zero references to the String
>> > org.hibernate.engine.Mapping.
>> >
>> > I just kicked off a run of the ORM / Java 9 Jenkins job to see if it has
>> > the same failure.
>> >
>> > Anyone have any ideas?
>> >
>> >
>>
> ___
>> 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
Re: [hibernate-dev] CDI integration in Hibernate ORM and the Application scope
On Tue, Jan 2, 2018 at 2:42 PM, Steve Ebersole 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 wrote: > >> On Wed, Dec 20, 2017 at 9:48 AM, Sanne Grinovero >> 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 >> 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
Re: [hibernate-dev] ORM & Java 9 - strange javadoc failure
What's even more strange is that if I build just spatial's javadoc it works
fine. If I try to build the aggregated javadoc is when I see this (even
though I've removed those lines)
On Wed, Jan 3, 2018 at 8:36 AM Steve Ebersole wrote:
> Here is the version that triggered the Travis job:
>
>
> https://github.com/sebersole/hibernate-core/blob/5.3/hibernate-spatial/src/main/java/org/hibernate/spatial/dialect/oracle/SDOObjectMethod.java
>
> As you can see those (non-)references are removed. Same error.
>
> On Wed, Jan 3, 2018 at 3:32 AM Yoann Rodiere wrote:
>
>> Steve, there is a reference to org.hibernate.engine.Mapping in a
>> non-javadoc comment with a javadoc tag
>> ("@see"):
>> org.hibernate.spatial.dialect.oracle.SDOObjectProperty#getReturnType
>> Also: org.hibernate.spatial.dialect.oracle.SDOObjectMethod#getReturnType
>> Maybe you could try removing/fixing this comment and see how it goes? The
>> bug may be about the javadoc processor trying to process non-javadoc
>> comments whenever it sees a javadoc tag... Which could be worked around
>> easily.
>>
>> Yoann Rodière
>> Hibernate NoORM Team
>> yo...@hibernate.org
>>
>> On 2 January 2018 at 20:15, Steve Ebersole wrote:
>>
>>> Sanne, have you had a chance to look at this? If not, I may have to just
>>> disable Java 9 from Travis
>>>
>>
>>> On Wed, Dec 27, 2017 at 8:37 PM Steve Ebersole
>>> wrote:
>>>
>>> > I worked on getting Travis CI set up on ORM for reasons discussed here
>>> > previously. But I am running into a really strange error when I
>>> enabled
>>> > Java 9:
>>> >
>>> > javadoc: error - An exception occurred while building a component:
>>> > ClassSerializedForm
>>> > (com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
>>> > org.hibernate.engine.Mapping not found)
>>> > Please file a bug against the javadoc tool via the Java bug reporting
>>> page
>>> > (http://bugreport.java.com) after checking the Bug Database (
>>> > http://bugs.java.com)
>>> > for duplicates. Include error messages and the following diagnostic in
>>> > your report. Thank you.
>>> > com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
>>> > org.hibernate.engine.Mapping not found
>>> >
>>> > It seems like javadoc is complaining because it sees a reference to a
>>> > class (org.hibernate.engine.Mapping) that it cannot find. It is true
>>> that
>>> > there is no class named org.hibernate.engine.Mapping, the real name is
>>> > org.hibernate.engine.spi.Mapping - but what is strange is that I
>>> search the
>>> > entire ORM project and found zero references to the String
>>> > org.hibernate.engine.Mapping.
>>> >
>>> > I just kicked off a run of the ORM / Java 9 Jenkins job to see if it
>>> has
>>> > the same failure.
>>> >
>>> > Anyone have any ideas?
>>> >
>>> >
>>>
>> ___
>>> 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
Re: [hibernate-dev] ORM & Java 9 - strange javadoc failure
OK, I've wasted way too much time on this. I'm just going to remove Java 9
from the Travis script.
On Wed, Jan 3, 2018 at 10:22 AM Steve Ebersole wrote:
> What's even more strange is that if I build just spatial's javadoc it
> works fine. If I try to build the aggregated javadoc is when I see this
> (even though I've removed those lines)
>
> On Wed, Jan 3, 2018 at 8:36 AM Steve Ebersole wrote:
>
>> Here is the version that triggered the Travis job:
>>
>>
>> https://github.com/sebersole/hibernate-core/blob/5.3/hibernate-spatial/src/main/java/org/hibernate/spatial/dialect/oracle/SDOObjectMethod.java
>>
>> As you can see those (non-)references are removed. Same error.
>>
>> On Wed, Jan 3, 2018 at 3:32 AM Yoann Rodiere wrote:
>>
>>> Steve, there is a reference to org.hibernate.engine.Mapping in a
>>> non-javadoc comment with a javadoc tag
>>> ("@see"):
>>> org.hibernate.spatial.dialect.oracle.SDOObjectProperty#getReturnType
>>> Also: org.hibernate.spatial.dialect.oracle.SDOObjectMethod#getReturnType
>>> Maybe you could try removing/fixing this comment and see how it goes?
>>> The bug may be about the javadoc processor trying to process non-javadoc
>>> comments whenever it sees a javadoc tag... Which could be worked around
>>> easily.
>>>
>>> Yoann Rodière
>>> Hibernate NoORM Team
>>> yo...@hibernate.org
>>>
>>> On 2 January 2018 at 20:15, Steve Ebersole wrote:
>>>
Sanne, have you had a chance to look at this? If not, I may have to
just
disable Java 9 from Travis
>>>
On Wed, Dec 27, 2017 at 8:37 PM Steve Ebersole
wrote:
> I worked on getting Travis CI set up on ORM for reasons discussed here
> previously. But I am running into a really strange error when I
enabled
> Java 9:
>
> javadoc: error - An exception occurred while building a component:
> ClassSerializedForm
> (com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
> org.hibernate.engine.Mapping not found)
> Please file a bug against the javadoc tool via the Java bug reporting
page
> (http://bugreport.java.com) after checking the Bug Database (
> http://bugs.java.com)
> for duplicates. Include error messages and the following diagnostic in
> your report. Thank you.
> com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
> org.hibernate.engine.Mapping not found
>
> It seems like javadoc is complaining because it sees a reference to a
> class (org.hibernate.engine.Mapping) that it cannot find. It is true
that
> there is no class named org.hibernate.engine.Mapping, the real name is
> org.hibernate.engine.spi.Mapping - but what is strange is that I
search the
> entire ORM project and found zero references to the String
> org.hibernate.engine.Mapping.
>
> I just kicked off a run of the ORM / Java 9 Jenkins job to see if it
has
> the same failure.
>
> Anyone have any ideas?
>
>
>>> ___
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
Re: [hibernate-dev] ORM CI jobs - erroneous github triggers
So I just pushed to the ORM master branch, which has caused the following jobs to be queued up: - hibernate-orm-5.0-h2 - hibernate-orm-5.1-h2 - hibernate-orm-master-h2-main Only one of those jobs is configured to "watch" master. So why do these other jobs keep getting triggered? I see the same exact thing on my personal fork as well. At the same time I pushed to my fork's 5.3 branch, which triggered the 6.0 job to be queued. On Tue, Jan 2, 2018 at 1:54 PM Steve Ebersole wrote: > The legacy ORM jobs (5.1-based ones at least) are getting triggered when > they should not be. Generally they all show they the run is triggered by a > "SCM change", but it does not show any changes. The underlying problem > (although I am at a loss as to why) is that there has indeed been SCM > changes pushed to Github, but against completely different branches. As > far as I can tell these job's Github setting are correct. Any ideas what > is going on? > > This would not be such a big deal if the CI environment did not throttle > all waiting jobs down to one active job. So the jobs I am actually > interested in are forced to wait (sometimes over an hour) for these jobs > that should not even be running. > > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] ORM CI jobs - erroneous github triggers
Hi Steve, this rings a bell, we had this bug in the past and apparently it's regressed again :( The latest Jenkins bug seems to be: - https://issues.jenkins-ci.org/browse/JENKINS-42161 I'll try the suggested workarount, aka to enable SCM poll without any frequency. Thanks, Sanne On 3 January 2018 at 17:35, Steve Ebersole wrote: > So I just pushed to the ORM master branch, which has caused the following > jobs to be queued up: > > >- hibernate-orm-5.0-h2 >- hibernate-orm-5.1-h2 >- hibernate-orm-master-h2-main > > Only one of those jobs is configured to "watch" master. So why do these > other jobs keep getting triggered? > > I see the same exact thing on my personal fork as well. At the same time I > pushed to my fork's 5.3 branch, which triggered the 6.0 job to be queued. > > > > On Tue, Jan 2, 2018 at 1:54 PM Steve Ebersole wrote: > >> The legacy ORM jobs (5.1-based ones at least) are getting triggered when >> they should not be. Generally they all show they the run is triggered by a >> "SCM change", but it does not show any changes. The underlying problem >> (although I am at a loss as to why) is that there has indeed been SCM >> changes pushed to Github, but against completely different branches. As >> far as I can tell these job's Github setting are correct. Any ideas what >> is going on? >> >> This would not be such a big deal if the CI environment did not throttle >> all waiting jobs down to one active job. So the jobs I am actually >> interested in are forced to wait (sometimes over an hour) for these jobs >> that should not even be running. >> >> >> > ___ > 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
Re: [hibernate-dev] ORM CI jobs - erroneous github triggers
I've made the change on: - hibernate-orm-5.0-h2 - hibernate-orm-5.1-h2 - hibernate-orm-master-h2-main Let's see if it helps, then we can figure out a way to check all jobs are using this workaround. On 3 January 2018 at 18:12, Sanne Grinovero wrote: > Hi Steve, > > this rings a bell, we had this bug in the past and apparently it's > regressed again :( > > The latest Jenkins bug seems to be: > - https://issues.jenkins-ci.org/browse/JENKINS-42161 > > I'll try the suggested workarount, aka to enable SCM poll without any > frequency. > > Thanks, > Sanne > > > On 3 January 2018 at 17:35, Steve Ebersole wrote: >> So I just pushed to the ORM master branch, which has caused the following >> jobs to be queued up: >> >> >>- hibernate-orm-5.0-h2 >>- hibernate-orm-5.1-h2 >>- hibernate-orm-master-h2-main >> >> Only one of those jobs is configured to "watch" master. So why do these >> other jobs keep getting triggered? >> >> I see the same exact thing on my personal fork as well. At the same time I >> pushed to my fork's 5.3 branch, which triggered the 6.0 job to be queued. >> >> >> >> On Tue, Jan 2, 2018 at 1:54 PM Steve Ebersole wrote: >> >>> The legacy ORM jobs (5.1-based ones at least) are getting triggered when >>> they should not be. Generally they all show they the run is triggered by a >>> "SCM change", but it does not show any changes. The underlying problem >>> (although I am at a loss as to why) is that there has indeed been SCM >>> changes pushed to Github, but against completely different branches. As >>> far as I can tell these job's Github setting are correct. Any ideas what >>> is going on? >>> >>> This would not be such a big deal if the CI environment did not throttle >>> all waiting jobs down to one active job. So the jobs I am actually >>> interested in are forced to wait (sometimes over an hour) for these jobs >>> that should not even be running. >>> >>> >>> >> ___ >> 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
Re: [hibernate-dev] ORM CI jobs - erroneous github triggers
Nice! Glad you found something. Thanks for making the changes. On Wed, Jan 3, 2018 at 12:16 PM Sanne Grinovero wrote: > I've made the change on: >- hibernate-orm-5.0-h2 >- hibernate-orm-5.1-h2 >- hibernate-orm-master-h2-main > > Let's see if it helps, then we can figure out a way to check all jobs > are using this workaround. > > > On 3 January 2018 at 18:12, Sanne Grinovero wrote: > > Hi Steve, > > > > this rings a bell, we had this bug in the past and apparently it's > > regressed again :( > > > > The latest Jenkins bug seems to be: > > - https://issues.jenkins-ci.org/browse/JENKINS-42161 > > > > I'll try the suggested workarount, aka to enable SCM poll without any > frequency. > > > > Thanks, > > Sanne > > > > > > On 3 January 2018 at 17:35, Steve Ebersole wrote: > >> So I just pushed to the ORM master branch, which has caused the > following > >> jobs to be queued up: > >> > >> > >>- hibernate-orm-5.0-h2 > >>- hibernate-orm-5.1-h2 > >>- hibernate-orm-master-h2-main > >> > >> Only one of those jobs is configured to "watch" master. So why do these > >> other jobs keep getting triggered? > >> > >> I see the same exact thing on my personal fork as well. At the same > time I > >> pushed to my fork's 5.3 branch, which triggered the 6.0 job to be > queued. > >> > >> > >> > >> On Tue, Jan 2, 2018 at 1:54 PM Steve Ebersole > wrote: > >> > >>> The legacy ORM jobs (5.1-based ones at least) are getting triggered > when > >>> they should not be. Generally they all show they the run is triggered > by a > >>> "SCM change", but it does not show any changes. The underlying problem > >>> (although I am at a loss as to why) is that there has indeed been SCM > >>> changes pushed to Github, but against completely different branches. > As > >>> far as I can tell these job's Github setting are correct. Any ideas > what > >>> is going on? > >>> > >>> This would not be such a big deal if the CI environment did not > throttle > >>> all waiting jobs down to one active job. So the jobs I am actually > >>> interested in are forced to wait (sometimes over an hour) for these > jobs > >>> that should not even be running. > >>> > >>> > >>> > >> ___ > >> 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
Re: [hibernate-dev] CDI integration in Hibernate ORM and the Application scope
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 wrote: > On Tue, Jan 2, 2018 at 2:42 PM, Steve Ebersole > 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 wrote: >> >>> On Wed, Dec 20, 2017 at 9:48 AM, Sanne Grinovero >>> 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 >>> 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'
