[HSEARCH] Rename elasticsearch artifact
by Davide D'Alto
At the moment the elasticsearch integration artifactid is:
hibernate-search-backend-elasticsearch
Elasticsearch is actually more than just a backend (we use this term for
the jGroups and JMS integration). I think we should rename it to:
hibernate-search-elasticsearch
Thanks,
Davide
10 years, 1 month
HHH-8999/HHH-10413 and Comparable IDs
by Gail Badner
ExecutableList#add attempts to keep track of whether the Executable objects
are sorted. [1]
Except for entity insert actions (which use InsertActionSorter),
ExecutableList#add uses the following to determine if adding the current
Executable to the end invalidates the sort:
if ( previousLast != null && previousLast.compareTo( executable ) > 0 ) {
sorted = false;
}
EntityAction#compareTo compares the IDs for the current and previous
EntityAction if they have different entity names; similarly,
CollectionAction compares the collection keys for the current and previous
CollectionAction if they have different entity names.
In most cases, the ID class implements Comparable, although I don't know of
any requirement that says this needs to be true.
This breaks down when a byte[] ID is used as described by HHH-8999. The
reason is that AbstractTypeDescriptor#comparator is null because it is
assigned like this:
this.comparator = Comparable.class.isAssignableFrom( type )
? (Comparator<T>) ComparableComparator.INSTANCE
: null;
PrimitiveByteArrayTypeDescriptor does not override
AbstractTypeDescriptor#getComparator, so null is returned ultimately
causing a NullPointerException in AbstractStandardBasicType#compare:
public final int compare(Object x, Object y) {
return javaTypeDescriptor.getComparator().compare( (T) x, (T) y );
}
The same happens for PrimitiveCharacterArrayTypeDescriptor,
ByteArrayTypeDescriptor, and CharacterArrayTypeDescriptor. Are there others?
According to HHH-10413, this also affects version attributes.
Here are a couple of alternatives:
A) create comparators for PrimitiveCharacterArrayTypeDescriptor,
ByteArrayTypeDescriptor, and CharacterArrayTypeDescriptor.
B) Change AbstractTypeDescriptor#comparator to:
this.comparator = Comparable.class.isAssignableFrom( type )
? (Comparator<T>) ComparableComparator.INSTANCE
: IncomparableComparator.INSTANCE;
IncomparableComparator#compare always returns 0, so that comparison would
never invalidate the sort.
Does it make sense to sort Executable objects by an ID or collection key
that is an array? In other words, would such IDs be generated in a natural
order? If not, I think B) makes more sense.
Thoughts?
Thanks,
Gail
[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...
10 years, 1 month
Trouble with blog for ORM 5.0.9
by Gail Badner
Hibernate ORM 5.0.9.Final is released. Everything is done except the
announcements.
I did `rake preview` and saw that my blog displayed correctly locally, so I
cherry-picked the commit with my blog to production and pushed the commit.
It's been over an hour and I still don't see it on http://in.relation.to/.
I tried `rake clean preview` on the production branch and now I see:
***************************************************************************
Starting preview server at http://localhost:4242 (Press Ctrl-C to shutdown)
***************************************************************************
[2016-03-14 22:23:50] INFO WEBrick 1.3.1
[2016-03-14 22:23:50] INFO ruby 2.2.1 (2015-02-26) [x86_64-linux]
rake aborted!
ERROR: Running Awestruct failed.
/home/gbadner/git/in.relation.to-again/Rakefile:104:in `run_awestruct'
/home/gbadner/git/in.relation.to-again/Rakefile:64:in `block in <top
(required)>'
/home/gbadner/.rvm/gems/ruby-2.2.1/bin/ruby_executable_hooks:15:in `eval'
/home/gbadner/.rvm/gems/ruby-2.2.1/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => preview
(See full trace by running task with --trace)
Anyone have any idea what is wrong?
Thanks,
Gail
10 years, 1 month
Preparations for releasing Hibernate ORM 5.0.9.final
by Gail Badner
I am preparing to do the release.
I forgot to send an email about not pushing fixes after Sunday to allow us
to complete our testing before releasing 5.0.9.Final today. Unfortunately,
fixes for HHH-10592 and HHH-10608 were pushed after tests were successfully
completed.
I see that a CI test is failing:
http://ci.hibernate.org/job/hibernate-orm-5.0-h2/lastCompletedBuild/testR...
.
I need to move forward with the 5.0.9 release and do not have time to
investigate what is going wrong with the CI test and to re-run the
necessary tests, so I will revert the fixes for HHH-10592 and HHH-10608 to
get back to the state at which we know the tests are successful. After
releasing, I will change the version to 5.0.10-SNAPSHOT, and re-apply the
commits so they will be fixed in 5.0.10.
I still need to update the migration guide (HHH-10542). After doing so, I
will start the release. Please do not push any other commits until after
5.0.9.Final is released.
Any issues that are scheduled for 5.0.9 that are not resolved will be moved
to 5.0.10.
Thanks,
Gail
10 years, 1 month
Everyone: Need volunteers for mentoring GSOC
by Sanne Grinovero
Hi all,
earlier today in our IRC meeting [1] we discussed ideas for Google
Summer of Code;
mostly related Hibernate Search but not only:
Quoting the previous summary by Gunnar:
1 - Java Batch API job for HSEARCH mass indexing
2 - Solr backend
3 - HSEARCH support for JHipster
4 - HSEARCH support for Spring Data
5 - Async API for ORM/OGM/HSEARCH
[It's not a closed list, you can also propose additional ideas.]
is anyone on this mailing list interested enough on these subjects to
volunteer mentoring?
I mentored two students last year and we had nice results, but I won't
be able to mentor this summer.
It would need to be someone who's regularly contributing already, and
ideally someone familiar with the technology we're integrating with:
most of the above proposals are about integrating with some other
standard or framework.
For example I wouldn't mentor on JHipster as all I know about it is
what I've seen in a couple of presentations... but if the student is
not too junior he can also be tasked with reaching out to "the other"
community to get guidance.
But for that I'd want us to be able to make some introductions at
least, to have some kind of "co-mentor" volunteered by the other
community/project.
Thanks,
Sanne
1 - http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/...
10 years, 1 month
Returned mail: Data format error
by The Post Office
The original message was received at Fri, 11 Mar 2016 14:06:24 +0800
from lists.jboss.org [101.45.215.108]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
10 years, 1 month
The PAR archive test case validity - PackagedEntityManagerTest
by Vlad Mihalcea
Hi,
I have two tests in the PackagedEntityManagerTest unit test that fail on my
machine, but work just fine for everybody else.
It could be an OS thing or not, but during the check, I found hat we are
testing against an use case that is not found in the JPA spec.
The testExternalJar() creates an externaljar.jar and an explicitpar.par.
I found an old reference on the PAR archive (
http://radio-weblogs.com/0135826/2005/07/07.html) but the JPA 2.1 doesn't
mention anything about it.
The explicitpar.par contains the persistence.xml which contains a jar-file
attribute that references the externaljar.jar with an absolute path:
<jar-file>D:\Vlad\Work\GitHub\hibernate-orm\hibernate-entitymanager\target/packages/externaljar.jar</jar-file>
The JPA spec says that: "Such JAR files are specified relative to the
directory or jar file that contains the root of the persistence unit", and
gives several examples
for when using an EAR with or without a WAR.
While debugging, I found that the JarFileBasedArchiveDescriptor scans the
"explicitpar.par" and looks for:
if ( getEntryBasePrefix() != null && ! entryName.startsWith(
getEntryBasePrefix() ) ) {
continue;
}
where the getEntryBasePrefix() is
"D:/Vlad/Work/GitHub/hibernate-orm/hibernate-entitymanager/target/packages/externaljar.jar"
The way that JarFileBasedArchiveDescriptor is implemented matches the JPA
description.
Nevertheless, the scan cannot locate the jar, and the entities that are
contained in the "externaljar.jar" don't get loaded, and the test fails.
I can ignore this on my machine and just consider it a white noise, but I
wonder why we still check for PAR when we might want to have a test with an
EAR instead and relative paths.
Vlad
10 years, 1 month
