Regarding extended bean managers and the CDI spec
by Benjamin Confino
Hello
Just a quick FYI for hibernate developers and anyone else who might be
implementing extended bean managers.
When I asked the mailing list for advice in implementing extended bean
managers I was advised to call beanManagerInitialized during
AfterBeanDiscovery if at all possible. However AfterBeanDiscovery triggers
a call to BeanManager.createInstance(), and according to the CDI 2.0 spec
section 11.3 an exception is thrown if createInstance is called before
AfterDeploymentValidation. I was able to get it working by invoking
beanManagerInitialized during the AfterDeploymentValidation event. However
I wanted to check with you that you think that's going to work ok incase I
missed anything; and bring this to everyone's attention just encase it is
helpful.
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, 8 months
- 2
- 1
JDK 13 , JDK 14 & Valhalla Early Access builds are available.
by Rory O'Donnell
Hi Sanne,
**OpenJDK* 13 Early Access build **28 is now available **at : -
jdk.java.net/13/*
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Changes in this build 28 [1]
*Reminder of a change in b24 - A jrt URI can only encode paths to files
in /modules tree **(JDK-8224946
<https://bugs.openjdk.java.net/browse/JDK-8224946>)*
A |jrt| URL is a hierarchical URI with syntax |jrt:/[$MODULE[/$PATH]]|.
When using the |jrt| file system, a |java.net.URI| object can be created
with the |java.nio.file.Path::toUri| method to encode a normalized path
to a file in the |/modules| tree. A |jrt| URL cannot encode a path to a
file in the |/packages| tree. The |jrt| file system provider has changed
in this release so that |toUri| fails with |IOError| when it is not
possible to encode the file path as a jrt URI. *This change may impact
tools have been making use of URLs that are not compliant with the
syntax. Tools with paths to files in **|/packages|**can use the
**|toRealPath()|**method to obtain the real path (in **|/modules|**)
before attempting to convert the file path to a URI.*
*OpenJDK 14 **Early Access build 4 **is now available **at : -
jdk.java.net/14/*
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Changes in this build [2]
*Project Valhalla "L-World Inline Types" Early-Access Builds*
* Build jdk-14-valhalla+1-8
* These early-access builds are provided under the GNU General Public
License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Please send feedback via e-mail to valhalla-dev(a)openjdk.java.net
<mailto:valhalla-dev@openjdk.java.net>. To send e-mail to this
address you must first subscribe to the mailing list.
*The Skara tooling is now open source *[3]
we are happy to announce that the tooling for project Skara is now open
source and available at
* https://github.com/openjdk/skara <https://github.com/openjdk/skara.>
The Skara tooling includes both server-side tools (so called "bots") as
well as several command-line tools **
If you have any questions, feedback etc. send them to Skara mailing list [4]
Rgds, Rory
[1] JDK 13 - Changes in b28 here
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B27%22%3A...>
[2] JDK 14 - Changes in b4 here
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B3%22%3A%...>
[3] https://mail.openjdk.java.net/pipermail/skara-dev/2019-June/000047.html
[4] https://mail.openjdk.java.net/mailman/listinfo/skara-dev
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
6 years, 9 months
- 1
- 0
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, 9 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, 9 months
- 2
- 2