[hibernate-dev] NoORM IRC meeting minutes

2019-07-02 Thread Guillaume Smet
Hi,

Here are the minutes of this week's NoORM meeting.

Have a nice day.

=

15:00 < gsmet> #topic Progress Davide
15:00 < yrodiere> hi
15:01 < gsmet> DavideD: you there?
15:01 < DavideD> Yes
15:01 < DavideD> Hi
15:01 < gsmet> hi :)
15:01 < DavideD> I'm currently working on improving the security score of
our websites
15:01 < DavideD> You can see the result for in.relation.to here:
https://observatory.mozilla.org/analyze/in.relation.to
15:01 < jbossbot> Title: Mozilla Observatory
15:01 < DavideD> If you are curious
15:02 < DavideD> I think I'm almost done with it and it still missing some
changes on the way we add javascripts to reach the A score
15:03 < gsmet> yeah I suppose you need to include the hash?
15:03 < DavideD> Yes for some and also avoid having inline scripts
15:03 < gsmet> ah OK
15:04 < DavideD> I'm working on that right now
15:04 < gsmet> cool
15:04 < DavideD> The main issue I have is that some code is added when we
include the javascript and I need to figure out if we can avoid it
15:05 < DavideD> But we don't need necessarly on A score, right now we are
B and it's already much better than before
15:05 < DavideD> *need on A score
15:05 < DavideD> I think that's the main thing from me
15:06 < gsmet> #topic Next 2 weeks Davide
15:06 < DavideD> Today I think I will finish with in.relation.to and then I
have to apply the same changes to hibernate.org
15:06 < gsmet> the code should be very similar
15:07 < gsmet> I really tried to be consistent when I worked on the refresh
15:07 < DavideD> Yes, but some changes can only be applied on Apache and we
serve hibernate.org on github pages
15:07 < gsmet> yes, right
15:08 < DavideD> I think I will have some work to do on CI as well once we
solved the issues with it
15:09 < DavideD> I think that's all from me
15:09 < gsmet> so, CI is pretty critical as it totally prevents us from
doing NoORM releases
15:09 < gsmet> (at least not without taking the risk to miss something when
doing the release)
15:09 < DavideD> Yes, also the websites release if we want to apply some
changes
15:10 < gsmet> yes, right
15:10 < DavideD> TO be fair, the scripts can be run locally
15:10 < gsmet> (at least not without taking the risk to miss something when
doing the release) <-
15:10 < gsmet> I agree we can do without but it's a big step backwards
15:10 < gsmet> and a risk I don't really want to take
15:10 < DavideD> Got it, but CI was just running the scripts as far as I
remember, so it shouldn't be to critical
15:11 < DavideD> But I'm not eager to do it :)
15:11 < gsmet> I don't mind having a big digest authentication for a while
if we need it
15:11 < gsmet> yeah, the thing is we release at a fast pace on Search (for
alphas) and Validator (for Quarkus)
15:11 < yrodiere> It's about having a constant build environment, too.
15:11 < gsmet> yeah
15:12 < gsmet> you could push artifacts built with JDK 11 or whatever
15:12 < gsmet> well, there were good reasons why we use CI to release
15:12 < gsmet> so let's not say now that we can do without because it's
really a risk I don't want to take
15:12 < DavideD> I'm not suggesting we should stop using CI :) Hopefully we
will have new machines soon, I will check with Sanne about it
15:14 < gsmet> DavideD: anything else?
15:14 < DavideD> No, thanks
15:14 < gsmet> OK, thanks!
15:14 < gsmet> #topic Progress Guillaume
15:14 < gsmet> so I fixed some issues in HV, one being quite annoying for
Quarkus
15:14 < gsmet> I would need a release :]
15:15 < gsmet> I also updated Quarkus to Search Alpha7
15:15 < gsmet> I gave a talk in Lille about Quarkus and my demo was based
on Search
15:15 < yrodiere> \o/
15:15 < gsmet> same comment as for any occasion I had to talk about Search:
people don't know s**t about it
15:16 < gsmet> we need to advertise it a bit more I think
15:16 < gsmet> I will do my part in Quarkus talks
15:16 < gsmet> but if we have some opportunity to talk about it, let's not
waste it
15:16 < gsmet> that's pretty much it on the Hibernate side
15:17 < gsmet> #topic Next 2 weeks Guillaume
15:17 < gsmet> having the ability to release HV in ~one week would be nice
15:17 < gsmet> I would be able to fix an annoying issue in the next Quarkus
release
15:17 < gsmet> other than that, nothing big planned
15:18 < gsmet> I will focus more on data in Quarkus for the next sprints
15:18 < gsmet> so more ORM/HV/Search work but mostly in Quarkus itself to
improve the integration
15:18 < gsmet> that's it for me
15:18 < gsmet> #topic Progress Yoann
15:19 < yrodiere> I started with a few bug fixes, related to method handles
in GraalVM, distance projections, ...
15:19 < yrodiere> I also fixed a few problems with the APIs, mostly
renaming some DSL interfaces and using a more consistent package structure
for
  annotations
15:19 < yrodiere> I upgraded Search to ES 7.2 and 6.8, nothing new here
15:19 < yrodiere> I released 6.0.0.Alpha7
15:20 < yrodiere> And most of last week I was busy with restoring entity
loading in search queries
15:20 < 

Re: [hibernate-dev] NotYetReadyException with extended bean manager

2019-07-02 Thread Benjamin Confino
Thank you for your suggestions. 

I think it's unlikely that we're passing in a null bean manager, but the 
suggestion about calling them in the proper order sounds like it could be 
the answer, so I will try that first. Hopefully that will resolve the 
matter. 

Regards
Benjamin



From:   Yoann Rodiere 
To: Benjamin Confino 
Cc: Hibernate Dev 
Date:   02/07/2019 07:26
Subject:Re: [hibernate-dev] NotYetReadyException with extended 
bean manager



Hello,

> what happens between 
ExtendedBeanManagerSynchronizer.beanManagerInitialized and 
ContainerManagedLifecycleStrategy$BeanImpl.resolveContainerInstance to 
result in this error?

Judging from your stack trace, it seems an instance of 
org.hibernate.resource.beans.container.internal.ContainerManagedLifecycleStrategy.BeanImpl
 
was passed a null BeanManager.
The only place we create an instance of BeanImpl relies on 
org.hibernate.resource.beans.container.internal.CdiBasedBeanContainer#getUsableBeanManager
 
to retrieve the bean manager.
When using an extended bean manager, this method should only return null 
in a very specific case and, as far as I can tell, only if you passed a 
null entityManager to 
org.hibernate.resource.beans.container.internal.CdiBeanContainerExtendedAccessImpl#beanManagerInitialized.
In any case, there's something that was not properly initialized in the 
CdiBasedBeanContainer.

Since this only happens when Hibernate Search is initialized, it is 
possible that the ExtendedBeanManager's LifecycleListeners were called out 
of order? I.e. Hibernate Search's listener was called before Hibernate 
ORM's, leading to Hibernate Search starting to initialize before Hibernate 
ORM had a chance to set the entity manager. Make sure you call the 
lifecycle listeners in the order they were passed to 
org.hibernate.resource.beans.container.spi.ExtendedBeanManager#registerLifecycleListener.

If that doesn't solve the problem, I think we'll need a reproducer to 
investigate.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org


On Mon, 1 Jul 2019 at 23:49, Benjamin Confino  wrote:
Hello

I have a stack, see the attached file, where there is a 
NotYetReadyException. This is after liberty invokes 
ExtendedBeanManagerSynchronizer.beanManagerInitialized, and we are passing 

in a bean manager to hibernate. 

My question is what happens between 
ExtendedBeanManagerSynchronizer.beanManagerInitialized and 
ContainerManagedLifecycleStrategy$BeanImpl.resolveContainerInstance to 
result in this error? Is it still using the same BeanManager we passed in 
- and if so what could cause a NotYetReadyException when a bean manager is 

there? Or does hibernate try to acquire a second bean manager? If so what 
method does hibernate use to acquire the bean manager?

Regards
Benjamin



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev