Re: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules

[Steve Ebersole]

Of course I meant "continuing with Javassist..." :P

On Tue, Jan 2, 2018 at 3:50 PM Steve Ebersole  wrote:

> ASM is a completely different model though, unless the part you think
> could be used here is different.
>
> I did say though that we could leverage Jandex for this part.  The problem
> (iiuc) there though is that Jandex would require all classes to be indexed
> - we could not just ask it to index a particular file and then get that
> "class descriptor" from the IndexView.
>
> So I agree, unless there is a better option someone proposes (and honestly
> is willing to work on), I think continuing with Jandex for the scanning
> piece is going to be the route we go for 5.3
>
> On Tue, Jan 2, 2018 at 3:23 PM Gunnar Morling 
> wrote:
>
>> 2017-12-29 21:34 GMT+01:00 Steve Ebersole :
>>
>>> On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole 
>>> wrote:
>>>

 * When using ByteBuddy as the byte code provider, I still needed to have
> Javassist around, as it's used in ClassFileArchiveEntryHandler. I
> understand that eventually this should be using Jandex, but I'm
> wondering
> whether we could (temporarily) change it to use ASM instead of
> Javassist
> (at least when using ByteBuddy as byte code provider, which is based on
> ASM), so people don't need to have Javassist *and* ByteBuddy when
> using the
> latter as byte code provider? This seems desirable esp. once we move to
> ByteBuddy by default.
>

 Yes, Sanne brought this up in Paris and it is something I will look at
 prior to a 5.3.0.Final

>>>
>>> Actually this is different than what Sanne brought up.  I actually
>>> cannot reproduce what Sanne is reporting.  If I had to guess he was not
>>> specifying the bytecode provider to use "globally".  This is a special kind
>>> of setting (we used to have a few) that can only be specified per-VM :
>>> either as a root `hibernate.properties` or as a System property.  It has to
>>> do with how Hibernate builds its mapping model, specifically
>>> `org.hibernate.mapping.Component`.  Given the redesign of the bootstrap
>>> process we may actually be able to remove that "VM wide" requirement.  I'll
>>> look into that for 5.3.  BTW Sanne, I created a repo[1] showing that this
>>> does indeed work when specified "properly".
>>>
>>> Gunnar, what you are seeing is very different and I'm not sure of a way
>>> to solve that yet.  That is all part of auto-discovery of resources
>>> (entities, embeddables, converters, etc) during bootstrap.  We need to
>>> inspect the file without loading the Class to look at its annotations.  We
>>> need *something* to do that, whether that is Jandex, Javassist, etc.  Byte
>>> Buddy may or may not have a similar facility.  The problem here is that the
>>> Javassist dependency is needed for a very different purpose.  And without a
>>> viable alternative solution, its going to have to stay that way.
>>>
>>
>> Yes, understood it's for a different purpose. I don't think ByteBuddy
>> itself will help with this task, but IIUC, ASM could be used to do so.
>> ButeBuddy depends on ASM, there's one caveat, though, ASM isn't pulled in
>> as a (transitive) dependency, but instead shaded into the ByteBuddy JAR.
>> See the discussion at the bottom of http://bytebuddy.net/ (section
>> "dependency maintenance") for details, it seems they recommend to shade ASM
>> yourself to avoid any version conflicts.
>>
>> Not sure really what's the best here, might not be worth the hazzle and
>> perhaps easiest just to live with the situation until this code has been
>> migrated to Jandex.
>>
>>
>>> [1] https://github.com/sebersole/orm-bytebuddy-no-javassist
>>>
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules

[Steve Ebersole]

ASM is a completely different model though, unless the part you think could
be used here is different.

I did say though that we could leverage Jandex for this part.  The problem
(iiuc) there though is that Jandex would require all classes to be indexed
- we could not just ask it to index a particular file and then get that
"class descriptor" from the IndexView.

So I agree, unless there is a better option someone proposes (and honestly
is willing to work on), I think continuing with Jandex for the scanning
piece is going to be the route we go for 5.3

On Tue, Jan 2, 2018 at 3:23 PM Gunnar Morling  wrote:

> 2017-12-29 21:34 GMT+01:00 Steve Ebersole :
>
>> On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole 
>> wrote:
>>
>>>
>>> * When using ByteBuddy as the byte code provider, I still needed to have
 Javassist around, as it's used in ClassFileArchiveEntryHandler. I
 understand that eventually this should be using Jandex, but I'm
 wondering
 whether we could (temporarily) change it to use ASM instead of Javassist
 (at least when using ByteBuddy as byte code provider, which is based on
 ASM), so people don't need to have Javassist *and* ByteBuddy when using
 the
 latter as byte code provider? This seems desirable esp. once we move to
 ByteBuddy by default.

>>>
>>> Yes, Sanne brought this up in Paris and it is something I will look at
>>> prior to a 5.3.0.Final
>>>
>>
>> Actually this is different than what Sanne brought up.  I actually cannot
>> reproduce what Sanne is reporting.  If I had to guess he was not specifying
>> the bytecode provider to use "globally".  This is a special kind of setting
>> (we used to have a few) that can only be specified per-VM : either as a
>> root `hibernate.properties` or as a System property.  It has to do with how
>> Hibernate builds its mapping model, specifically
>> `org.hibernate.mapping.Component`.  Given the redesign of the bootstrap
>> process we may actually be able to remove that "VM wide" requirement.  I'll
>> look into that for 5.3.  BTW Sanne, I created a repo[1] showing that this
>> does indeed work when specified "properly".
>>
>> Gunnar, what you are seeing is very different and I'm not sure of a way
>> to solve that yet.  That is all part of auto-discovery of resources
>> (entities, embeddables, converters, etc) during bootstrap.  We need to
>> inspect the file without loading the Class to look at its annotations.  We
>> need *something* to do that, whether that is Jandex, Javassist, etc.  Byte
>> Buddy may or may not have a similar facility.  The problem here is that the
>> Javassist dependency is needed for a very different purpose.  And without a
>> viable alternative solution, its going to have to stay that way.
>>
>
> Yes, understood it's for a different purpose. I don't think ByteBuddy
> itself will help with this task, but IIUC, ASM could be used to do so.
> ButeBuddy depends on ASM, there's one caveat, though, ASM isn't pulled in
> as a (transitive) dependency, but instead shaded into the ByteBuddy JAR.
> See the discussion at the bottom of http://bytebuddy.net/ (section
> "dependency maintenance") for details, it seems they recommend to shade ASM
> yourself to avoid any version conflicts.
>
> Not sure really what's the best here, might not be worth the hazzle and
> perhaps easiest just to live with the situation until this code has been
> migrated to Jandex.
>
>
>> [1] https://github.com/sebersole/orm-bytebuddy-no-javassist
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules

[Gunnar Morling]

2017-12-29 21:34 GMT+01:00 Steve Ebersole :

> On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole 
> wrote:
>
>>
>> * When using ByteBuddy as the byte code provider, I still needed to have
>>> Javassist around, as it's used in ClassFileArchiveEntryHandler. I
>>> understand that eventually this should be using Jandex, but I'm wondering
>>> whether we could (temporarily) change it to use ASM instead of Javassist
>>> (at least when using ByteBuddy as byte code provider, which is based on
>>> ASM), so people don't need to have Javassist *and* ByteBuddy when using
>>> the
>>> latter as byte code provider? This seems desirable esp. once we move to
>>> ByteBuddy by default.
>>>
>>
>> Yes, Sanne brought this up in Paris and it is something I will look at
>> prior to a 5.3.0.Final
>>
>
> Actually this is different than what Sanne brought up.  I actually cannot
> reproduce what Sanne is reporting.  If I had to guess he was not specifying
> the bytecode provider to use "globally".  This is a special kind of setting
> (we used to have a few) that can only be specified per-VM : either as a
> root `hibernate.properties` or as a System property.  It has to do with how
> Hibernate builds its mapping model, specifically 
> `org.hibernate.mapping.Component`.
> Given the redesign of the bootstrap process we may actually be able to
> remove that "VM wide" requirement.  I'll look into that for 5.3.  BTW
> Sanne, I created a repo[1] showing that this does indeed work when
> specified "properly".
>
> Gunnar, what you are seeing is very different and I'm not sure of a way to
> solve that yet.  That is all part of auto-discovery of resources (entities,
> embeddables, converters, etc) during bootstrap.  We need to inspect the
> file without loading the Class to look at its annotations.  We need
> *something* to do that, whether that is Jandex, Javassist, etc.  Byte Buddy
> may or may not have a similar facility.  The problem here is that the
> Javassist dependency is needed for a very different purpose.  And without a
> viable alternative solution, its going to have to stay that way.
>

Yes, understood it's for a different purpose. I don't think ByteBuddy
itself will help with this task, but IIUC, ASM could be used to do so.
ButeBuddy depends on ASM, there's one caveat, though, ASM isn't pulled in
as a (transitive) dependency, but instead shaded into the ByteBuddy JAR.
See the discussion at the bottom of http://bytebuddy.net/ (section
"dependency maintenance") for details, it seems they recommend to shade ASM
yourself to avoid any version conflicts.

Not sure really what's the best here, might not be worth the hazzle and
perhaps easiest just to live with the situation until this code has been
migrated to Jandex.


> [1] https://github.com/sebersole/orm-bytebuddy-no-javassist
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] ORM CI jobs - erroneous github triggers

[Steve Ebersole]

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] Realising the JavaDoc jars as well

[Steve Ebersole]

This is already what I have done over a week ago ;)

On Tue, Jan 2, 2018 at 1:43 PM Chris Cranford  wrote:

> I agree with Andrea.
>
>
> On 12/29/2017 09:14 AM, andrea boriero wrote:
>
> +1 for filtering out internal packages.
>
> not a strong opinion on grouping
>
> On 24 December 2017 at 14:23, Steve Ebersole  
>  wrote:
>
>
> Sure, but the question remains :P  It just adds another one:
>
>
>1. Should internal packages be generated into the javadocs (individual
>and/or aggregated)?
>2. Should the individual javadocs (only intended for publishing to
>Central) group the packages into api/spi(/internal) the way we do for
> the
>aggregated javadocs?
>
> Personally I think filtering out internal packages is a great idea.
>
> Regarding grouping packages, I think its not worth the effort for the
> individual ones - just have an overview for these that just notes this
> distinction.
>
> On Sat, Dec 23, 2017 at 6:53 AM Sanne Grinovero  
> 
> wrote:
>
>
> On 22 December 2017 at 18:16, Steve Ebersole  
> 
>
> wrote:
>
> I wanted to get everyone's opinion about the api/spi/internal package
> grouping we do in the aggregated Javadoc in regards to the per-module
> javadocs.  Adding this logic adds significant overhead to the process
>
> of
>
> building the Javadoc, to the point where I am considering not
>
> performing
>
> that grouping there.
>
> Thoughts?
>
>
> For Hibernate Search we recently decided to not produce javadocs at
> all for "internal"; everything else is just documented as a single
> group.
>
> That cuts on the "need to know" complexity of end users. Advanced
> users who could have benefitted from knowing more about the internals
> will likely have sources.
>
>
>
> On Tue, Dec 12, 2017 at 11:37 AM Vlad Mihalcea <
>
> mihalcea.v...@gmail.com>
>
> wrote:
>
>
> I tested it locally, and when publishing the jars to Maven local, the
> JavaDoc is now included.
>
> Don't know if there's anything to be done about it.
>
> Vlad
>
> On Mon, Dec 11, 2017 at 9:32 PM, Sanne Grinovero 
>  wrote:
>
>
> +1 to merge it (if it works - which I didn't check)
>
> Some history can easily be found:
>  -
>
>
> http://lists.jboss.org/pipermail/hibernate-dev/2017-January/015758.html
>
>
> Thanks,
> Sanne
>
>
> On 11 December 2017 at 15:24, Vlad Mihalcea <
>
> mihalcea.v...@gmail.com>
>
> wrote:
>
> Hi,
>
> I've noticed this Pull Request which is valid and worth
>
> integrating:
>
> https://github.com/hibernate/hibernate-orm/pull/2078
>
> Before I merge it, I wanted to make sure whether this change was
>
> accidental
>
> or intentional.
>
> Was there any reason not to ship the JavaDoc jars along with the
> release
> artifacts and the sources jars as well?
>
> Thanks,
> Vlad
> ___
> hibernate-dev mailing 
> listhibernate-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>  ___
> hibernate-dev mailing 
> listhibernate-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>  ___
> hibernate-dev mailing 
> listhibernate-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing 
> listhibernate-dev@lists.jboss.orghttps://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] Realising the JavaDoc jars as well

[Chris Cranford]

I agree with Andrea.

On 12/29/2017 09:14 AM, andrea boriero wrote:
> +1 for filtering out internal packages.
>
> not a strong opinion on grouping
>
> On 24 December 2017 at 14:23, Steve Ebersole  wrote:
>
>> Sure, but the question remains :P  It just adds another one:
>>
>>
>>1. Should internal packages be generated into the javadocs (individual
>>and/or aggregated)?
>>2. Should the individual javadocs (only intended for publishing to
>>Central) group the packages into api/spi(/internal) the way we do for
>> the
>>aggregated javadocs?
>>
>> Personally I think filtering out internal packages is a great idea.
>>
>> Regarding grouping packages, I think its not worth the effort for the
>> individual ones - just have an overview for these that just notes this
>> distinction.
>>
>> On Sat, Dec 23, 2017 at 6:53 AM Sanne Grinovero 
>> wrote:
>>
>>> On 22 December 2017 at 18:16, Steve Ebersole 
>> wrote:
 I wanted to get everyone's opinion about the api/spi/internal package
 grouping we do in the aggregated Javadoc in regards to the per-module
 javadocs.  Adding this logic adds significant overhead to the process
>> of
 building the Javadoc, to the point where I am considering not
>> performing
 that grouping there.

 Thoughts?
>>> For Hibernate Search we recently decided to not produce javadocs at
>>> all for "internal"; everything else is just documented as a single
>>> group.
>>>
>>> That cuts on the "need to know" complexity of end users. Advanced
>>> users who could have benefitted from knowing more about the internals
>>> will likely have sources.
>>>
 On Tue, Dec 12, 2017 at 11:37 AM Vlad Mihalcea <
>> mihalcea.v...@gmail.com>
 wrote:
> I tested it locally, and when publishing the jars to Maven local, the
> JavaDoc is now included.
>
> Don't know if there's anything to be done about it.
>
> Vlad
>
> On Mon, Dec 11, 2017 at 9:32 PM, Sanne Grinovero  wrote:
>
>> +1 to merge it (if it works - which I didn't check)
>>
>> Some history can easily be found:
>>  -
>>
>>> http://lists.jboss.org/pipermail/hibernate-dev/2017-January/015758.html
>> Thanks,
>> Sanne
>>
>>
>> On 11 December 2017 at 15:24, Vlad Mihalcea <
>> mihalcea.v...@gmail.com>
>> wrote:
>>> Hi,
>>>
>>> I've noticed this Pull Request which is valid and worth
>> integrating:
>>> https://github.com/hibernate/hibernate-orm/pull/2078
>>>
>>> Before I merge it, I wanted to make sure whether this change was
>> accidental
>>> or intentional.
>>>
>>> Was there any reason not to ship the JavaDoc jars along with the
>>> release
>>> artifacts and the sources jars as well?
>>>
>>> Thanks,
>>> Vlad
>>> ___
>>> 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
>>
> ___
> 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

[Steve Ebersole]

Scott, how would we register a listener for this event?  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.

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) 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 

Re: [hibernate-dev] CDI integration in Hibernate ORM and the Application scope

[Scott Marlow]

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) 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 

Re: [hibernate-dev] ORM & Java 9 - strange javadoc failure

[Steve Ebersole]

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

Re: [hibernate-dev] Realising the JavaDoc jars as well

[Sanne Grinovero]

On 24 December 2017 at 14:23, Steve Ebersole  wrote:
> Sure, but the question remains :P  It just adds another one:

What I meant to suggest is:
if we agree that we're not going to bother with publishing javadocs
for "internal", we're effectively getting rid of one of the 3
"groups"; one to go..

Personally I believe the SPI/API package differentiation is a gray
area anough to not need physical separation of javadoc archives, so
I'd just make a single javadoc output for all SPI/API.


> Should internal packages be generated into the javadocs (individual and/or
> aggregated)?
> Should the individual javadocs (only intended for publishing to Central)
> group the packages into api/spi(/internal) the way we do for the aggregated
> javadocs?
>
> Personally I think filtering out internal packages is a great idea.
>
> Regarding grouping packages, I think its not worth the effort for the
> individual ones - just have an overview for these that just notes this
> distinction.

+1 to keep it simple, for both us and users: I don't think people will
want to learn about the techniques we use to keep our projects organized
as a pre-requisite to be able to find the javadocs they are after.

Thanks,
Sanne


>
> On Sat, Dec 23, 2017 at 6:53 AM Sanne Grinovero  wrote:
>>
>> On 22 December 2017 at 18:16, Steve Ebersole  wrote:
>> > I wanted to get everyone's opinion about the api/spi/internal package
>> > grouping we do in the aggregated Javadoc in regards to the per-module
>> > javadocs.  Adding this logic adds significant overhead to the process of
>> > building the Javadoc, to the point where I am considering not performing
>> > that grouping there.
>> >
>> > Thoughts?
>>
>> For Hibernate Search we recently decided to not produce javadocs at
>> all for "internal"; everything else is just documented as a single
>> group.
>>
>> That cuts on the "need to know" complexity of end users. Advanced
>> users who could have benefitted from knowing more about the internals
>> will likely have sources.
>>
>> >
>> > On Tue, Dec 12, 2017 at 11:37 AM Vlad Mihalcea 
>> > wrote:
>> >>
>> >> I tested it locally, and when publishing the jars to Maven local, the
>> >> JavaDoc is now included.
>> >>
>> >> Don't know if there's anything to be done about it.
>> >>
>> >> Vlad
>> >>
>> >> On Mon, Dec 11, 2017 at 9:32 PM, Sanne Grinovero 
>> >> wrote:
>> >>
>> >> > +1 to merge it (if it works - which I didn't check)
>> >> >
>> >> > Some history can easily be found:
>> >> >  -
>> >> >
>> >> > http://lists.jboss.org/pipermail/hibernate-dev/2017-January/015758.html
>> >> >
>> >> > Thanks,
>> >> > Sanne
>> >> >
>> >> >
>> >> > On 11 December 2017 at 15:24, Vlad Mihalcea 
>> >> > wrote:
>> >> > > Hi,
>> >> > >
>> >> > > I've noticed this Pull Request which is valid and worth
>> >> > > integrating:
>> >> > >
>> >> > > https://github.com/hibernate/hibernate-orm/pull/2078
>> >> > >
>> >> > > Before I merge it, I wanted to make sure whether this change was
>> >> > accidental
>> >> > > or intentional.
>> >> > >
>> >> > > Was there any reason not to ship the JavaDoc jars along with the
>> >> > > release
>> >> > > artifacts and the sources jars as well?
>> >> > >
>> >> > > Thanks,
>> >> > > Vlad
>> >> > > ___
>> >> > > 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