[hibernate-dev] Re: HCANN evolution
I am needing to release this, but a combination of changes in the JBoss Nexus authentication process and the fact we're using an older version of Gradle made this much more complicated than I wanted; so I began the process to transfer HCANN to bintray as well. ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[hibernate-dev] Re: HCANN evolution
On Thu, Oct 22, 2020 at 9:00 AM Sanne Grinovero wrote: > On Thu, 22 Oct 2020 at 14:50, Steve Ebersole wrote: > > N.B. I'm considering these steps as a preparation step, I didn't yet > address the core of the memory retention issue - I'll get to that > next, having simplified the problem first. > Awesome, thanks! It is possible that dom4j itself might be causing some of the perf problems ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[hibernate-dev] Re: HCANN evolution
On Thu, 22 Oct 2020 at 14:50, Steve Ebersole wrote: > > Sounds good, I'll take a look. Thanks, here is a draft PR for ORM master: - https://github.com/hibernate/hibernate-orm/pull/3608 > > Longer term, the best option from the perspective of ORM is to simply drop > HCANN altogether in favor of Jandex + JAXB. In fact, I am considering > playing with that on top of your work. It would be awesome to start dropping > the things that hold us to including dom4j +100 :) Further such steps should be easier after this. N.B. I'm considering these steps as a preparation step, I didn't yet address the core of the memory retention issue - I'll get to that next, having simplified the problem first. > > On Thu, Oct 22, 2020 at 8:02 AM Yoann Rodiere wrote: >> >> Hi, >> >> Looks good to me, but please ping me when you submit the PR. HCANN is used >> in Hibernate Search as well, and not just the ORM module. >> If we ever need to have two ORM modules in Hibernate Search (one for ORM 5 >> and one for ORM 6), I'll need to be sure that Hibernate Search can switch >> from HCANN 5 to 6 without recompiling... >> >> >> Yoann Rodière >> Hibernate Team >> yo...@hibernate.org >> >> >> On Thu, 22 Oct 2020 at 14:51, Sanne Grinovero wrote: >> >> > Hi all, >> > >> > While investigating a case of too much memory being held after boot, I >> > noticed Hibernate Commons Annotations's old design and patterns are a >> > strong contributor to the problem. >> > >> > We talked many times about getting rid of it, yet we know it's not >> > easy as we have a high level of coupling - but I believe we can >> > achieve it in iterative steps, reducing the coupling. >> > >> > I now have a draft of patches which remove its capability to load >> > classes and packages "by name"; this implies it removing any >> > interaction with classloaders, and associated complexity; this will of >> > course require some adaptation in ORM but it turns out its own code is >> > also cleaner as a result (ORM's ClassLoaderService is preferred), so >> > I'd like to proceed. >> > >> > Unless there are strong objections, I'll mark all those classes which >> > I mean to delete as deprecated in HCANN 5.x, and remove them in HCANN >> > master (6). >> > Then I'll release the next 5.x and propose the adaptation PR to ORM; >> > since I'm not actually removing the functionality yet we still have >> > the option to keep the ORM patches limited to a smaller scope, should >> > there be any concerns regarding specific details (to be discussed in >> > PRs), but I don't believe this should be necessary. >> > >> > I'd also like to release an HCANN 6 preview and have ORM6 use it. >> > >> > Among other benefits, this will leave the HCANN codebase significantly >> > smaller and more focused on its core goals; I believe after this >> > cleanup it looks much better and we might not need to fully get rid of >> > it, for example it does solve the generics problem quite elegantly, so >> > there's no need to throw that out too. >> > >> > Thanks, >> > Sann >> > ___ >> > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org >> > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org >> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> ___ >> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org >> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[hibernate-dev] Re: HCANN evolution
Sounds good, I'll take a look. Longer term, the best option from the perspective of ORM is to simply drop HCANN altogether in favor of Jandex + JAXB. In fact, I am considering playing with that on top of your work. It would be awesome to start dropping the things that hold us to including dom4j On Thu, Oct 22, 2020 at 8:02 AM Yoann Rodiere wrote: > Hi, > > Looks good to me, but please ping me when you submit the PR. HCANN is used > in Hibernate Search as well, and not just the ORM module. > If we ever need to have two ORM modules in Hibernate Search (one for ORM 5 > and one for ORM 6), I'll need to be sure that Hibernate Search can switch > from HCANN 5 to 6 without recompiling... > > > Yoann Rodière > Hibernate Team > yo...@hibernate.org > > > On Thu, 22 Oct 2020 at 14:51, Sanne Grinovero wrote: > > > Hi all, > > > > While investigating a case of too much memory being held after boot, I > > noticed Hibernate Commons Annotations's old design and patterns are a > > strong contributor to the problem. > > > > We talked many times about getting rid of it, yet we know it's not > > easy as we have a high level of coupling - but I believe we can > > achieve it in iterative steps, reducing the coupling. > > > > I now have a draft of patches which remove its capability to load > > classes and packages "by name"; this implies it removing any > > interaction with classloaders, and associated complexity; this will of > > course require some adaptation in ORM but it turns out its own code is > > also cleaner as a result (ORM's ClassLoaderService is preferred), so > > I'd like to proceed. > > > > Unless there are strong objections, I'll mark all those classes which > > I mean to delete as deprecated in HCANN 5.x, and remove them in HCANN > > master (6). > > Then I'll release the next 5.x and propose the adaptation PR to ORM; > > since I'm not actually removing the functionality yet we still have > > the option to keep the ORM patches limited to a smaller scope, should > > there be any concerns regarding specific details (to be discussed in > > PRs), but I don't believe this should be necessary. > > > > I'd also like to release an HCANN 6 preview and have ORM6 use it. > > > > Among other benefits, this will leave the HCANN codebase significantly > > smaller and more focused on its core goals; I believe after this > > cleanup it looks much better and we might not need to fully get rid of > > it, for example it does solve the generics problem quite elegantly, so > > there's no need to throw that out too. > > > > Thanks, > > Sann > > ___ > > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org > > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > ___ > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[hibernate-dev] Re: HCANN evolution
On Thu, 22 Oct 2020 at 14:36, Guillaume Smet wrote: > > On Thu, Oct 22, 2020 at 3:30 PM Sanne Grinovero wrote: >> >> Sure, I'll do that. >> >> Regarding Validator, I believe it doesn't use it? > > No, it doesn't! Great! thanks ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[hibernate-dev] Re: HCANN evolution
Sure, I'll do that. Regarding Validator, I believe it doesn't use it? On Thu, 22 Oct 2020 at 14:02, Yoann Rodiere wrote: > > Hi, > > Looks good to me, but please ping me when you submit the PR. HCANN is used in > Hibernate Search as well, and not just the ORM module. > If we ever need to have two ORM modules in Hibernate Search (one for ORM 5 > and one for ORM 6), I'll need to be sure that Hibernate Search can switch > from HCANN 5 to 6 without recompiling... > > > Yoann Rodière > Hibernate Team > yo...@hibernate.org > > > On Thu, 22 Oct 2020 at 14:51, Sanne Grinovero wrote: >> >> Hi all, >> >> While investigating a case of too much memory being held after boot, I >> noticed Hibernate Commons Annotations's old design and patterns are a >> strong contributor to the problem. >> >> We talked many times about getting rid of it, yet we know it's not >> easy as we have a high level of coupling - but I believe we can >> achieve it in iterative steps, reducing the coupling. >> >> I now have a draft of patches which remove its capability to load >> classes and packages "by name"; this implies it removing any >> interaction with classloaders, and associated complexity; this will of >> course require some adaptation in ORM but it turns out its own code is >> also cleaner as a result (ORM's ClassLoaderService is preferred), so >> I'd like to proceed. >> >> Unless there are strong objections, I'll mark all those classes which >> I mean to delete as deprecated in HCANN 5.x, and remove them in HCANN >> master (6). >> Then I'll release the next 5.x and propose the adaptation PR to ORM; >> since I'm not actually removing the functionality yet we still have >> the option to keep the ORM patches limited to a smaller scope, should >> there be any concerns regarding specific details (to be discussed in >> PRs), but I don't believe this should be necessary. >> >> I'd also like to release an HCANN 6 preview and have ORM6 use it. >> >> Among other benefits, this will leave the HCANN codebase significantly >> smaller and more focused on its core goals; I believe after this >> cleanup it looks much better and we might not need to fully get rid of >> it, for example it does solve the generics problem quite elegantly, so >> there's no need to throw that out too. >> >> Thanks, >> Sann >> ___ >> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org >> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[hibernate-dev] Re: HCANN evolution
Hi, Looks good to me, but please ping me when you submit the PR. HCANN is used in Hibernate Search as well, and not just the ORM module. If we ever need to have two ORM modules in Hibernate Search (one for ORM 5 and one for ORM 6), I'll need to be sure that Hibernate Search can switch from HCANN 5 to 6 without recompiling... Yoann Rodière Hibernate Team yo...@hibernate.org On Thu, 22 Oct 2020 at 14:51, Sanne Grinovero wrote: > Hi all, > > While investigating a case of too much memory being held after boot, I > noticed Hibernate Commons Annotations's old design and patterns are a > strong contributor to the problem. > > We talked many times about getting rid of it, yet we know it's not > easy as we have a high level of coupling - but I believe we can > achieve it in iterative steps, reducing the coupling. > > I now have a draft of patches which remove its capability to load > classes and packages "by name"; this implies it removing any > interaction with classloaders, and associated complexity; this will of > course require some adaptation in ORM but it turns out its own code is > also cleaner as a result (ORM's ClassLoaderService is preferred), so > I'd like to proceed. > > Unless there are strong objections, I'll mark all those classes which > I mean to delete as deprecated in HCANN 5.x, and remove them in HCANN > master (6). > Then I'll release the next 5.x and propose the adaptation PR to ORM; > since I'm not actually removing the functionality yet we still have > the option to keep the ORM patches limited to a smaller scope, should > there be any concerns regarding specific details (to be discussed in > PRs), but I don't believe this should be necessary. > > I'd also like to release an HCANN 6 preview and have ORM6 use it. > > Among other benefits, this will leave the HCANN codebase significantly > smaller and more focused on its core goals; I believe after this > cleanup it looks much better and we might not need to fully get rid of > it, for example it does solve the generics problem quite elegantly, so > there's no need to throw that out too. > > Thanks, > Sann > ___ > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
