HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
by Sanne Grinovero
Picking automatic module names for Hibernate Search isn't going to be
straight-forward as our two main jars (hibernate-search-engine &
hibernate-search-orm) suffer from split package among them.
We can't really fix the split package problem without breaking all
users, so if we want to consider that, we can debate it but that will
need to happen at another round as we're doing a minor release, so
let's focus on:
# Which names to pick
# Should we pick the names at all
# Which modules should have a name
For a great background on the possible strategies and pitfalls I
recommend reading Stephen Colebourne's blog on this subject [1].
He persuaded me there are good reasons to use the "reverse DNS, the
top level package", however since we have the split package problem we
can't simply go with that.
Still, we can respect the principles he recommends with a small
variation. It's fair to assume that the `org.hibernate.search` prefix
is "ours"; since the nature of the suggestion is focused on making
sure there are no misunderstandings in the community about which names
you can choose - as there is no central authority making sure module
names aren't clashing - we should be fine within Hibernate projects
with any `org.hibernate.X` prefix, as long as we coordinate and reach
an agreement on this list.
So, I propose we use:
Engine module:
- org.hibernate.search.engine
ORM integration module:
- org.hibernate.search.orm
JGroups, JMS backends:
[ no automatic module name ? Excepting some "guidelines" in the JMS
module, these are not public API so nobody would benefit from it -
also we think we might want to phase out the name "backend" in the
future ]
Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
- org.hibernate.search.elasticsearch
Elasticsearch / AWS security integration:
[ no automatic module name: no public API ]
Serialization / Avro
[ no automatic module name: no public API ]
WDYT?
We could also pick names for the ones which I've listed as "no public
API" but I see no point: as we're only assigning an "Automatic Module
Name" we won't be able to explicitly state that the other modules
depend on these. So nobody will use them, and things are a bit in flux
anyway in this area because of Hibernate Search 6 plans.
Another optional altogether: since we have split packages which we'll
have to resolve before we can actually transform these into fully
fledged modules, I think an acceptable position is also to say we
won't be publishing any automatic module name yet. Personally I'm
inclined to go with the names suggested above, at least some others
can start making baby steps, even if it's not all there.
# What I don't like:
For one, that the typical application will need to import both
`org.hibernate.search.engine` and `org.hibernate.search.orm`, and
likely more as well (e.g. Elasticsearch API, Lucene API module is
coming, ..).
Maybe similar to BOM's today we could publish a module which
statically imports multiple of these, that could be nicer to use but
we risk needing to publish (and document) one for each of a selection
of combinations. So let's not start with such things yet.
Thanks,
Sanne
[1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
6 years, 6 months
Null-Pointer Exception with 5.2.14
by Petar Tahchiev
Hi guys,
I have this exception with latest 5.2.14 (my project runs fine with 5.2.13):
Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
default] Unable to build Hibernate SessionFactory
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:970)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:895)
at
org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:57)
at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:365)
at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:387)
at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:376)
at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.afterPropertiesSet(LocalContainerEntityManagerFactoryBean.java:341)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706)
... 32 more
Caused by: org.hibernate.MappingException: Could not instantiate persister
org.hibernate.persister.entity.SingleTableEntityPersister
at
org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:112)
at
org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:77)
at
org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:128)
at
org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:300)
at
org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:460)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:892)
... 39 more
Caused by: java.lang.NullPointerException
at
org.hibernate.persister.entity.AbstractPropertyMapping.getSuperCollection(AbstractPropertyMapping.java:285)
at
org.hibernate.persister.entity.AbstractPropertyMapping.addPropertyPath(AbstractPropertyMapping.java:198)
at
org.hibernate.persister.entity.AbstractPropertyMapping.initPropertyPaths(AbstractPropertyMapping.java:395)
at
org.hibernate.persister.entity.AbstractEntityPersister.initOrdinaryPropertyPaths(AbstractEntityPersister.java:2300)
at
org.hibernate.persister.entity.AbstractEntityPersister.initPropertyPaths(AbstractEntityPersister.java:2347)
at
org.hibernate.persister.entity.AbstractEntityPersister.postConstruct(AbstractEntityPersister.java:3906)
at
org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:437)
at sun.reflect.GeneratedConstructorAccessor94.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:96)
... 44 more
--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
6 years, 8 months
Byte-buddy: default enhancer in 5.3 ? [HHH-11253]
by Sanne Grinovero
HHH-11253 is about making ByteBuddy the default implementation, but
it's flagged for 6.
I think that in Paris there was consensus to make it the default in
5.3 alredy, to possibly drop Javassist entirely in 6.0.
May I change this to 6 ? If that's ok, I can assign it to myself.
Thanks,
Sanne
6 years, 8 months
Should EntityManager#refresh retain an existing lock?
by Gail Badner
HHH-12257 involves refreshing an entity that is already has a pessimistic
lock. In the test case attached to the jira, EntityManager#refresh(Object
entity) is used to refresh the entity, instead of a method that specifies a
particular LockModetype (e.g., #refresh(Object entity, LockModeType
lockMode)). The lock on the refreshed entity is dropped.
A workaround is to determine the current lock mode using
Session#getCurrentLockMode, which returns a org.hibernate.LockMode object,
which can be converted to a LockModeType that can be used to call
EntityManager#refresh(Object entity, LockModeType lockMode).
Unfortunately, the code that converts org.hibernate.LockMode to
LockModeType is "internal" (org.hibernate.internal.util.LockModeConverter).
I'm on the fence about how this should work.
The API for EntityManager#refresh(Object entity) does not say that an
existing lock mode on the entity should be retained.
On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency section
seems to indicate that locks on an entity apply to the transaction, and
does say that a lock on an entity should be dropped when refreshed without
an specified LockModeType.
Does anyone have any guidance on how this should work?
Thanks,
Gail
6 years, 9 months
Why does implicit join translate to inner join?
by Lukas Eder
Hello,
Vlad Mihalcea [1] was so kind to point me to this mailing list with my
question about implicit joins. The user guide [2] states that:
"Implicit joins are always treated as inner joins."
To me, this seems wrong, semantically, if implicit joins follow optional
(nullable) foreign key relationships. Let's assume that customers have
optional addresses. When we write
SELECT c.firstName, c.lastName, c.address.city.country.code
FROM customer c
The resulting query will INNER JOIN the customer / address / city / country
tables, filtering out customers with no address, or addresses with no
cities, or cities with no countries (let's ignore the modelling aspect). In
fact, I got a CROSS JOIN with join predicate in the WHERE clause, but that
doesn't really change anything. Hence the SELECT clause applies a filter,
which is rather surprising. To me, this seems simply wrong just like it
would be wrong for Stream.map() to apply any filters.
However, I'm sure there must have been good reasons to default to this
behaviour, even in the presence of optional foreign keys.
Does anyone know what those reasons are?
Cheers,
Lukas
[1]: https://twitter.com/vlad_mihalcea/status/965927462684196864
[2]: http://docs.jboss.org/hibernate/orm/5.2/userguide/
html_single/Hibernate_User_Guide.html#hql-implicit-join
6 years, 9 months
Hibernate Search 5.10.0.Beta1 is out
by Yoann Rodiere
Hello,
We just published 5.10.0.Beta1, the first release in the 5.10 branch. This
release is designed to work with Hibernate ORM 5.3, which is still just a
Candidate Release. This means you can now test your applications relying on
ORM+Search with ORM 5.3 and Search 5.10.
Check out our blog for more information about this release:
http://in.relation.to/2018/02/23/hibernate-search-5-10-0-Beta1/
--
Yoann Rodiere
yoann(a)hibernate.org / yrodiere(a)redhat.com
Software Engineer
Hibernate NoORM team
6 years, 9 months
[OGM] Validating our artifacts don't rely on JBoss-only dependencies
by Yoann Rodiere
Hello,
TL;DR: can I move hibernate-ogm-infinispan-remote tests to the
integrationtest module, since they are actually integration tests?
During one of our previous IRC meetings, I mentioned that we did some
changes in the Hibernate Search POMs to remove the need for custom settings
when building. The idea was to hard-code the JBoss repositories in the POMs
of modules that need them, so that other modules would be built using Maven
Central only. This way, we would make sure our modules only rely on
dependencies that are available in Maven Central, not some obscure
artifacts only available in the JBoss Maven repository.
I am trying to do the same in OGM, but there is one problem: for this to be
possible at all, integration tests that do require those exotic
dependencies need to be in a separate Maven module.
It turns out some tests implemented in the infinispan-remote module require
to spin up an Infinispan server, which does have exotic dependencies (it's
basically a WildFly server, if I understood correctly).
Thus, in order to remove the need for custom settings when building, I
would need to move those tests to the integrationtest module. They are
integration tests, after all, since they need a running Infinispan server
to work.
Would anyone object to that?
--
Yoann Rodiere
yoann(a)hibernate.org / yrodiere(a)redhat.com
Software Engineer
Hibernate NoORM team
6 years, 9 months
