NoORM IRC meeting minutes
by 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 < yrodiere> the core feature was already there, but there were some
loose ends compared to Search 5
15:21 < yrodiere> I also had to work on a very strange issue that started
to happen after we started enforcing HTTPS on hibernate.org: multiple users
reported exceptions in their application as a result.
15:21 < yrodiere> it's related to XML parsers that download the DTD from
our website
15:22 < yrodiere> and as you can imagine, people using XML configuration
for ORM these days are not exactly using the latest version of their XML
parser
15:22 < yrodiere> which I think explains why it doesn't support redirection
or HTTPS very well
15:23 < yrodiere> I'm not sure what is wrong exactly, but it seems related
to the JBoss infrastructure (www.hibernate.org) and I asked the relevant
people to remove their redirection to HTTPS
15:23 < yrodiere> (which appeared out of nowhere, so I think they have some
sort of cache)
15:23 < yrodiere> anyway
15:23 < yrodiere> that's all for the past two weeks
15:23 < yrodiere> next
15:24 < gsmet> #topic Next 2 weeks Yoann
15:24 < yrodiere> I've had a few ideas recently to make the bridge 2.0 APIs
less "weird", so I'm trying that right now
15:24 < yrodiere> I'm not sure it will work out, but I'd rather try it
before I document these APIs, which will probably take a few days
15:24 < yrodiere> Then I intend to work a bit on missing features on the
Lucene side
15:24 < yrodiere> related to directory providers
15:24 < yrodiere> Mainly so that we can at least consider initiating the
work on the Infinispan Query upgrade,
15:24 < yrodiere> which could provide valuable insight
15:25 < yrodiere> that's all from me
15:25 < gsmet> ok, thanks
15:25 < gsmet> let me check but I think we are done
15:25 < gsmet> #endmeeting
=====
6 years, 4 months
- 1
- 0
NotYetReadyException with extended bean manager
by Benjamin Confino
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
6 years, 4 months
- 2
- 2