June 2017 - hibernate-dev - Jboss List Archives

Tuned Elasticsearch docker image for development / testing / demoing

by Sanne Grinovero

Hi, out of desperation for my laptop taking ages to run Hibernate Search / Elasticsearch tests, I created a new Docker image which improves my build times from 40 minutes to 5 minutes: - https://hub.docker.com/r/sanne/elasticsearch-light-testing/ - https://github.com/Sanne/elasticsearch-light-testing YMMV, it's great for my old laptop but only wins me a couple of seconds on the main workstation. Start it with: docker run -ti --tmpfs /run --tmpfs=/opt/elasticsearch/volatile/data:uid=1000 --tmpfs --tmpfs=/opt/elasticsearch/volatile/logs:uid=1000 -p 9200:9200 -p 9300:9300 --name es-it sanne/elasticsearch-light-testing Run the Hibernate Search testsuite with: mvn clean install -Dtest.elasticsearch.host.provided=true -Dtest.elasticsearch.host.url=http://localhost:9200 Thanks, Sanne

8 years, 6 months

1
0
0 / 0

SqlTypeDescriptor bind by name limitation

by Vlad Mihalcea

Hi, While writing an example for a custom Hibernate Type which supports PostgreSQL arrays, I realized that the SqlTypeDescriptor only supports bind by name: @Override protected void doBind(CallableStatement st, X value, String name, WrapperOptions options) throws SQLException { } However, for the java.sql.Array, we only have a bind by index method in java.sql.Statement: void setArray (int parameterIndex, Array x) throws SQLException; I remember that 6.0 is going to bind by index, so maybe this issue is already taken care of in the new version. Should we provide some fix for 5.x as well? Vlad

8 years, 6 months

3
4
0 / 0

Pull request

by Milo van der Zee

Hello, I submitted a pull request and fixed some issues with it (jUnit test and formatting) and after that nothing happens. How does this work? Do I just have to be patient or do I miss something? https://github.com/hibernate/hibernate-orm/pull/1906 MAG, Milo

8 years, 6 months

4
6
0 / 0

Let's avoid @hsearch.experimental javadoc tags in SPI

by Sanne Grinovero

== SPI have very long guarantees, anyway Considering that an SPI contract has relatively low SLAs I'd like to be way more "aggressive" in the removal of "this is experimental" notices. I'd also ask you all to consider not marking them as such, especially if the issue at hand feels properly sorted out. Most typically we'll have a notice like "This contract is currently under active development ". Anything which is marked as such and yet has not changed since the last minor release should no longer qualify as "active development", so we should clean it up and avoid scaring away potential users for no reason. WDYT? == What about API ? I am going to propose cleaning up the "experimental" tag from some selected APIs as well, yet in that case I don't think we should apply a similar reasoning as SPI (development activity) as time is not the right indicator. Some API has been marked experimental for a long time for good reasons: we might not have had the bandwidth (or interest) of finishing some related issue which could be essential for the feature to be actually used, and it might be problematic to fix such an half baked feature w/o being ale to make changes in the contract. == Reminder on changes Since we're on the subject... the API/SPI/impl classification is not black and white so bear in mind that any change we make will annoy someone. It's a tradeoff, but when you're making *any* change and have the opportunity to keep the contract backwards compatible, consider doing so. @Deprecated is a nice annotation. Of course this is not a reaction on any specific change; if any I'm just uncomfortable that I'm going to break a lot myself, and my own experience is that one can deal with some limited amount of compilation|compatibility issues but if we push too many "SPI & SPI- changes" in a single release people will get stuck on the older versions. We need to enable people to iterate in smaller milestones which are simpler to handle; if we're doing too much let's just make more intermediate minor releases. Thanks! Sanne

8 years, 6 months

3
4
0 / 0

NoORM IRC meeting minutes

by Guillaume Smet

Hi, Here are the minutes of the NoORM IRC meeting: 15:53 < jbott> Meeting ended Tue Jun 6 13:52:30 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:53 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/... 15:53 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/... 15:53 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/... Cheers, -- Guillaume

8 years, 6 months

1
0
0 / 0

Introducing a new API in Hibernate Search to "sign" HTTP requests to Elasticsearch

by Sanne Grinovero

Yoann has been working on allowing Hibernate Search users to use Elasticsearch on AWS. Specifically on AWS the Elasticsearch security can be configured to use application identities, which implies the requests need to be signed. A good background read can be found here [1]. We planned to allow people to use this but were not planning to include AWS specific libraries as dependencies - but since Yoann implemented an actual AWS signer in the tests I suppose it would be selfish to not ship it.. Please see the API proposal on github (with the PR): - https://github.com/hibernate/hibernate-search/pull/1426 Thanks, Sanne [1] - https://aws.amazon.com/blogs/security/how-to-control-access-to-your-amazo...

8 years, 6 months

3
15
0 / 0

Announcing: Early-Access builds of JDK 9 for Alpine Linux/musl at jdk.java.net/9/

by Rory O'Donnell

Hi Sanne, ** *Announcing: Early-Access builds of JDK 9 for Alpine Linux/musl at jdk.java.net/9/ [1] * * As of today there are pre-built Early-Access (EA) JDK binaries for Alpine Linux/musl at jdk.java.net/9/** o look for “Alpine Linux”. [1] * The Alpine Linux build is compatible with linux distributions that use the musl C library. *[2]* Feedback is very welcome via the portola-dev mailing list, remembering to subscribe to the mailing list first. *Proposed schedule change for JDK 9 [3]* JDK 9 Project continues to work toward the current goal of producing an initial Release Candidate build on 22 June. This proposal is to adjust the GA date in order to accommodate the additional time required to move through the JCP process. To be specific, we propose to move the GA date out by eight weeks, from 27 July to 21 September. Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/portola-dev/2017-June/000191.html [2] http://www.musl-libc.org/ [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-May/005864.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

8 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-dev June 2017