HHH-12172 - Bintray v. OSSRH
by Steve Ebersole
HHH-12172 is about moving away from the JBoss Nexus repo for publishing our
artifacts. There is an open question about which service to use instead -
Sonatype's OSSRH (Nexus) or JFrog's Bintray (Artifactory).
Personally I think Artifactory is far superior of a UI/platform. We all
know Nexus from the JBoss deployment of it, and we have all generally had
nothing good to say about it.
But I am wondering if anyone has practical experience with either, or knows
persons/projects tyay do and could share their experiences. E.g., even
though I prefer Bintray in almost every regard, I am very nervous that it
seems next to impossible to get help/support with it. The same may be true
with OSSRH - I don't know, hence why I am asking ;)
6 years, 11 months
CDI integration in Hibernate ORM and the Application scope
by Yoann Rodiere
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.
#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 careful, Application-scoped beans may not be able
to use Hibernate ORM from within their @PreDestroy methods... Which is
probably not a good idea. So we would have to find a solution together with
the WildFly team. Also to be considered: Hibernate Search would have to be
shut down just before the "early shut-down" of Hibernate ORM occurs,
because Hibernate Search cannot function at all without the beans it
retrieves from the CDI context.
Thoughts?
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
6 years, 11 months
ORM & Java 9 - strange javadoc failure
by Steve Ebersole
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?
6 years, 11 months
Using Hibernate ORM as automatic JPMS modules
by Gunnar Morling
Hi all,
Following to our discussion in Paris, I've created a simple test bed for
showing the usage of Hibernate ORM and its dependencies as automatic
modules for the Java 9 module system:
https://github.com/gunnarmorling/hibernate-orm-on-java9-modules
It pretty much works as expected, I couldn't reproduce the classloader
issue I was mentioning during the meeting. A few things worth noting:
* JDK 9 comes with an incomplete JTA module (java.transaction), so a
complete one must be provided via --upgrade-module-path (I'm using the
2.0.0.Alpha1 version Tomaz Cerar has created for that purpose)
* hibernate-jpa-2.1-api-1.0.0.Final.jar can't be used as an automatic
module, as the automatic naming algorithm stumples upon the numbers (2.1)
within the module name it derives; I'm therefore using my ModiTect tooling (
https://github.com/moditect/moditect/) to convert the JPA API JAR into an
explicit module on the fly
See
https://github.com/gunnarmorling/hibernate-orm-on-java9-modules/blob/mast...
for the actual test, which is run using the module path only (i.e. no
classpath).
A few things caught my attention:
* When using ByteBuddy as the byte code provider, a reads relationship must
be added from the user's module towards hibernate.core ("requires
hibernate.core"). This is due to the usage of
org.hibernate.proxy.ProxyConfiguration within the generated proxy classes.
Ideally no dependence to the JPA provider should be needed when solely
working with the JPA API (as this demo does), but I'm not sure whether this
can be avoided when using proxies (or could we construct proxies in a way
not requiring this dependence?).
* 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.
* Multiple methods in ReflectHelper call setAccessible() without checking
whether the method/field/constructor already is accessible. If we changed
that to only call setAccessible() if actually needed, people would have to
be a little bit less permissive in their module descriptor. It'd suffice
for them to declare "exports com.example.entities to hibernate.core"
instead of "opens com.example.entities to hibernate.core", unless they
mandate (private) field access for their entities.
The demo is very simple (insert and load of an entity with a lazy
association). If there's anything else you'd like to try out when using ORM
as JPMS modules, let me know or just fork the demo and try it out yourself
:)
Cheers,
--Gunnar
6 years, 11 months
Infinispan modules contains hibernate-search-orm
by Guillaume Smet
Hi,
I'm trying to upgrade OGM 5.2 to WildFly 11 so that we don't release
modules for an outdated version of WildFly when we'll push this release (I
already did the upgrade in my ORM 5.2 support branch so it's mostly
backporting and tracking issues).
I have an issue with the Infinispan modules (and I don't understand why we
didn't have the issue earlier but it's another subject).
They contain an hibernate-search-orm module pointing to an
org.hibernate:5.2 module, which means that we would need to deploy an ORM
5.2 in WildFly whereas I don't think it's necessary.
Is there a use case for having hibernate-search-orm in Infinispan? It's not
referenced in other modules of the Infinispan modules zip (
http://search.maven.org/#search|gav|1|g%3A"org.infinispan"%20AND%20a%3A"infinispan-wildfly-modules")
and the slot is very specific so I wouldn't expect people to deploy it and
use it outside of Infinispan.
I would vote for not distributing this module with the Infinispan modules
if it's not too much work.
--
Guillaume
7 years
Locking German and French forums
by Vlad Mihalcea
Hi,
I'm going to lock the German and French forums since users posts
question there from time to time,
and the questions remain answered.
If someone has anything against it, let me know. Otherwise, we should use
the English one until we move to Discourse.
Vlad
7 years
ManagedBeanRegistry - dependency injection support
by Steve Ebersole
https://hibernate.atlassian.net/browse/HHH-11259 and friends are mainly
about back porting the work I did on 6.0 for the ManagedBeanRegistry
abstraction over dependency injection containers. We will ship support for
CDI as well as non-managed beans (things we directly instantiate). Of
course we'd ideally make it easy to plug in other DI containers such as
Spring. So I wanted to discuss the configuration of this support.
The first thing to consider is whether we want to support using multiple DI
containers simultaneously. E.g. is it conceivable that an application
might want to use both CDI and Spring simultaneously? I started building
in support for that via a CompositeManagedBeanRegistry implementation, but
stepping back I want to gauge whether that is "reasonable" before
continuing down that path
Assuming that we do want to support such "compositions" the next question
is how we see this being configured. Clearly any time a CDI BeanManager is
present during bootstrap we want to enable CDI ManagedBeanRegistry
support. How would users indicate additional ManagedBeanRegistry impls be
added to the CompositeManagedBeanRegistry? I have opinions about this, but
I'd like to hear other's thoughts...
Note that ManagedBeanRegistry is a service and is initiated
via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it
would be possible to completely redefine ManagedBeanRegistry support simply
by replacing that initiator.
A minor point... notice that the package name here is
`org.hibernate.resource.cdi`, even though one of the goals here is to
support non-CDI ManagedBeanRegistry impls. Do we want to use a different
package name? Maybe `org.hibernate.resource.beans`?
``org.hibernate.resource.di`? ``org.hibernate.resource.injection`?
Other suggestions? I'm actually ok with `org.hibernate.resource.cdi` - imo
"cdi" conveys the proper intent. But if others feel strongly it should be
something else, I am open to hearing what and why.
7 years
Hibernate Validator 6.0.7.Final released
by Guillaume Smet
Hi,
We just released Hibernate Validator 6.0.7.Final.
It adds a new @ISBN constraint and benefits from our latest performance
improvements.
It is based on the Bean Validation 2.0.1.Final API, which fixes a small
regression (that you shouldn't encounter in a standard usage of Bean
Validation).
Happy holidays to everyone!
--
Guillaume
7 years
