Hi,
I'll let it to actual Hibernate ORM developers (which I'm not) to give you
a proper answer (if they have one), but this seems like a bug to me. You
best course of action may be to provide a test case and provide it as part
of a ticket on JIRA: https://hibernate.atlassian.net/ .
If you really
I'll try to jump in. I'm mainly providing an external point of view though,
since I didn't seriously follow the progress of Java 9.
If I understood correctly, modules containing entities would not need to be
weak; they *could* be, as a quick solution to migrating to Java 9, but
ultimately the clea
(Don't know what's the status of this, since it's been discussed on IRC,
but jumping in just in case)
I tend to agree with Gunnar that storing the association on the owning side
of the association seems like a good idea. At least with an external point
of view, it seems like the right choice, but
Hi,
I wanted to start a discussion about this issue.
It's about stored field retrieval. When searching, Elasticsearch can return
field values two different ways:
* through the "_source" attribute [1], which basically provides a
copy-paste of the JSON that was submitted when indexing
* or throu
On 28 September 2016 at 15:23, Guillaume Smet
wrote:
>
> You won't be able to use these sorts of features:
> https://www.elastic.co/guide/en/elasticsearch/reference/curr
> ent/search-aggregations-bucket-datehistogram-aggregation.html
> https://www.elastic.co/guide/en/elasticsearch/reference/curr
>
Is there any particular reason why we would not want to create three
artifacts, besides backward compatibility? It seems the obvious and ideal
solution, but I might be missing something.
If there is common code, we can always create a fourth -neo4j-core artifact
that would have no interest to user
On 21 October 2016 at 12:20, Guillaume Smet
wrote:
> I always prefer to migrate early to the right solution when there is a
> compelling reason to do so and a clear logic in it.
I totally agree with that, but I think it's more about what we promised to
users than about what we think is the best
Hello,
I just finished assessing the required changes for supporting Elasticsearch
5.0. I put the details in this ticket:
https://hibernate.atlassian.net/browse/HSEARCH-2434
Here is a quick summary:
- Some (non-breaking) changes are required in Jest [1]
- We'll have to update the way we do
On 2 November 2016 at 12:59, Guillaume Smet
wrote:
> The other important point (mentioned in the issue but I think it's
> important to outline it here) concerning the analyzers is that they are now
> defined per index: there are no global analyzers, you have to define them
> for every index using
Hi team,
Just so you know, if you ever need to assert that a certain log is produced
in your JUnit tests, there's now a tool to do just that in Hibernate
Search: org.hibernate.search.test.util.impl.ExpectedLog4jLog [1]
You may use it much like you would use the ExpectedException rule:
public cla
Hi,
I just ran the test case, and there's something odd indeed: as Florian
said, @MapKeyJoinColumn in embeddables seem to be completely ignored when
the (embedded) association is overridden using @AssociationOverride. When
not using @AssociationOverride, everything works fine.
Vlad, do you think
Hello everyone,
We just released Hibernate Search 5.6.0.Beta4 and 5.7.0.Beta1, with the
latest bugfixes and previously missing features for our experimental
Elasticsearch integration.
For more information, please see our blog:
http://in.relation.to/2016/11/29/hibernate-search-5-6-0-Beta4-and-5-7
Hello everyone,
I'm currently working on HSEARCH-2219, "Define analyzers via the REST API",
whose purpose is to automatically translate @AnalyzerDefs in Hibernate
Search to settings in Elasticsearch, removing the need for users to
configure analyzers separately in their Elasticsearch instance.
Th
Hello everyone,
We just released Hibernate Search 5.6.0.CR1 and 5.7.0.Beta2, with the
latest bugfixes and previously missing features for our experimental
Elasticsearch integration.
This is the last step before 5.6 is released, so be sure to check it out so
you can share your thoughts with us bef
For what it's worth, changing the signature indeed seems appropriate to me:
the fewer object arrays, the better.
Your proposal would require making Query parameterized too, though. I'm not
really up-to-date with the current state of 6.0, but I guess it's already
done or being done.
Anyway, the onl
rized.
>
> Regarding JPA adopting scrolling as a feature, what I suggest simply
> follows what Hibernate ans JPA already do for other Query returns. Today
> it is completely inconsistent between Query#scroll and Query#list e.g.. I
> am just suggesting making that consistent.
&
e access rights),
but maybe the difference between OGM and Search lies there?
Anyway... I'm going for today, maybe I'll see something obvious tomorrow
morning!
Cheers,
Yoann Rodière
Hibernate NoORM Team
On 3 January 2017 at 18:22, Yoann Rodiere wrote:
> Thanks! Looking forward
Hello team,
I'm currently working on HSEARCH-2534, "Query-only analyzer definitions are
never added to the index settings with Elasticsearch".
This issue is about using analyzers only when querying with Elasticsearch.
It is already possible with Lucene, but not in Elasticsearch, because we
assume
y at query time
> differently than one which is used at indexing time.
> If there is need to clearly make such discrimination then this should
> be made very clear to our users too, so I'd prefer if we could avoid
> introducing new concepts for people to learn.. unless there
lyzerDef for query-only analyzers, and that we
allow using unknown analyzers in queries? I guess we could do that, but
that basically amounts to solution 3 "don't do it". Which is fine as long
as we plan to fix it later.
Also note we'd still have to explain users that query-o
Hi,
That's a catchy subject, now I'm sure I got Guillaume's (angry) attention :)
Sanne wanted us to think about feature removal... Here's a proposal.
The feature I'd like to deprecate/remove: automatic truncation of
date/calendars to a given resolution. It's used like that:
@Field
@CalendarBrid
:)
Yoann Rodière
Hibernate NoORM Team
On 9 January 2017 at 12:53, Guillaume Smet wrote:
> Hi,
>
> On Thu, Jan 5, 2017 at 5:20 PM, Yoann Rodiere wrote:
>
>> That's a catchy subject, now I'm sure I got Guillaume's (angry) attention
>> :)
>>
>&
Hello everyone,
We just released Hibernate Search 5.5.6.Final with the latest bugfixes.
For more information, please see our blog:
http://in.relation.to/2017/01/09/hibernate-search-5-5-6-Final/
Yoann Rodière
Hibernate NoORM Team
___
hibernate-dev mai
>
> I think it's a reasonable expectation, as long as we're talking
> specifically about mapping a *List* and not just a generic Collection.
>
Ah, this topic again :) I know I'll be all lone, but I'll try anyway!
If we do it for List, and unless there are technical issues that prevent us
from doi
some of which might ignore the ordering requirement.
> By doing so, you're explicitly telling both ORM and your other code
> interacting with the model that ignoring the order is acceptable.
>
> BTW I suspect mapping things as a generic Collection is a very unusual
> (or la
ed behavior... even if other dialects do
implement it.
If we really want to have a clear contract, it means we have to explicitly
state somewhere that ordering is undefined unless one is using @OrderColumn
/ @OrderBy. If we really want to do this, we may as well add "unless you're
using a
Hi,
Did the same this week-end, and adapted your work to match the bigger
picture of what we discussed on Friday.
Basically the "StructureTraverser" is now called "ValueProcessor", because
it's not responsible for exposing the internals of a structure anymore, but
only to process a structure accor
Everything you said seems to make sense to me, so +1.
We can see later whether we agree on the other common projects we could add
(checkstyle rules, test utils, ...), but I think there won't be many
arguments *against* them as long as there is no transitive dependency to
these projects for end user
One benefit we always get by being consistent is that it's easier for a
newcomer to switch from project to project... If it doesn't require more
work, we may as well be consistent.
Anyway, thanks Guillaume, I added this piece of information to the HSearch
ticket: https://hibernate.atlassian.net/br
On 30 January 2017 at 13:58, Guillaume Smet
wrote:
> Note that the current version of hibernate-commons-annotations is
> org.hibernate.common (without the s at the end, not org.hibernate as Yoann
> stated it).
>
You're right. Wouldn't the simplest solution be to use the same groupId
(without a "
Hello,
We just released Hibernate Search 5.6.0.Final, the first stable release
featuring experimental support for Elasticsearch (2.x).
We also started the candidate release phase for Hibernate Search 5.7 by
releasing version 5.7.0.CR1, with support for ORM 5.2.7 and newer (but not
older, see the
L91..L128
>
>
>
> 2017-02-06 16:49 GMT+01:00 Emmanuel Bernard :
> > Your prototype is very Hibernate Search tainted. I wonder how or whether
> we want it reusable across Hibernate Validator, Search and possibly more.
> >
> > Have you captured somewhere the discussion abou
Hello,
Following our recent (and successful) efforts to fix blocking issues on
https://github.com/mincong-h/gsoc-hsearch/, I recently added a branch on my
repo which contains the Hibernate Search codebase, with the addition of a
JSR-352 submodule. You can find the branch at [1]. The build is worki
Hello everyone,
We just released Hibernate Search 5.7.0.Final, compatible with Hibernate
ORM 5.2.8.
As 5.7 is not compatible with Hibernate ORM 5.0/5.1 anymore, we also
released a bugfix version for 5.6 with several backports: Hibernate Search
5.6.1.Final.
Be sure to check out our blog for more
Isn't marking those as "New feature" enough? Or, if necessary, tagging them?
I obviously can't tell how others use JIRA, but personally I don't dive
into old tickets every day. Most of the time I only check the new
(incoming) tickets and those assigned to the next release. So, those extra
tickets a
Hello,
Currently, the medata definition mechanisms in Search work this way:
- the primary way to define metadata is using annotations
- the secondary way to define metadata is programmatic, *but it only
instantiates annotations,* simulating annotated entities
- classes needing to acce
; working is very similar to annotations also has the side-effect of
> making the API intuitive for people who wish they could have added the
> annotation, but can't for some reason and have to fallback to this
> API: the picture they have in mind about their task is still similar
>
On 28 March 2017 at 10:03, Vlad Mihalcea wrote:
> There musts be a reason for choosing this ordering, but I can't figure out
> why the EntityDeleteAction was chosen to be executed last.
>
Isn't it simply to avoid foreign key constraints to explode? When you
update a reference to a foreign key *a
Hi,
I've moved the contributed dialect for OGM in this repository:
> https://github.com/DavideD/hibernate-ogm-contrib
Great, thanks :)
Which group id should we use? At the moment it is still
> org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib
>
+1 for org.hibernate.ogm.contrib. I
tegration.
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 27 April 2017 at 15:59, Yoann Rodiere wrote:
> I wonder, what's the benefit for HSEARCH-2616? Do you want to have that
> field so that we can just use AddLuceneWorks everywhere, and run targeted
> delete operations when we s
. I'll continue the
discussion on JIRA.
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 27 April 2017 at 18:19, Sanne Grinovero wrote:
> On 27 April 2017 at 15:11, Yoann Rodiere wrote:
> > I wonder, what's the benefit for HSEARCH-2616? Do you want to have that
> &g
Hi,
> * Can we have multiple indexes for the same entity, with different
> fields, geared towards different use cases?
No, it's not currently possible. Each entity is mapped to a single index.
But you can map each property of your entity to multiple index
"properties", so you can actually handle
Hello,
In our roadmap for 5.8, we have this:
Removal of class definitions from master nodes
> The integration of a "master node" needs to be simplified, both in terms
> of user configuration and implementation. We plan to not need user classes
> (entities) on such a node, so that in future it cou
Hello,
We just released Hibernate Search 5.8.0.Beta2, bringing us that much closer
to the final release.
You can find more information about 5.8 in general and the Beta2
specifically on our blog:
http://in.relation.to/2017/05/11/hibernate-search-5-8-0-Beta2/
Yoann Rodière
Hibernate NoORM Team
y
Sanne, the confusions you pointed out were:
- Thinking it's more efficient than other providers (it's not)
- Thinking it's integrated to replicated in-memory datastores such as
Infinispan (it's not)
So you'd want a name that says "it's not persistent" and probably "it's
easy to set up" w
>
> Did you instead consider to just let users provide their custom
> instance of org.elasticsearch.client.RestClient? It's still leaking an
> implementation detail of Hibernate Search, but at least it's one
> indirection less.
The only way to add AWS authentication to the RestClient is to use Ap
nt, if we want to allow
configuration (and in the case of an HTTP client, I'm afraid we have to),
we'll have to expose internals. We just have to make sure this is done in a
controlled way (expose as little as possible).
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 2 June
one. At the end of the day, that's
what really matters, right?
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 2 June 2017 at 14:25, Gunnar Morling wrote:
> 2017-06-02 12:49 GMT+02:00 Yoann Rodiere :
> >> There's an important difference: one exposes Apache HTTP
dière
Hibernate NoORM Team
yo...@hibernate.org
On 2 June 2017 at 14:47, Yoann Rodiere wrote:
> > There's no exposure of HTTP Client in this SPI. Yes, if people need to
> > customize the HTTP client to be used by the returned RestClient
> > instance, they'll naturally d
dded to
> RestClientBuilder? What's the benefit of this catch-up game?
>
>
>
>
> 2017-06-02 14:47 GMT+02:00 Yoann Rodiere :
> >> There's no exposure of HTTP Client in this SPI. Yes, if people need to
> >> customize the HTTP client to be used by the returned R
orling wrote:
> I reckon you are making fun of me. Anyways, I've had my say :)
>
> 2017-06-02 15:03 GMT+02:00 Yoann Rodiere :
> >> What's the benefit of this catch-up game?
> >
> > Not tainting our SPI with RestClient :)
> >
> > Yoann Rodière
&
Hi,
Answers below.
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 6 June 2017 at 18:48, Sanne Grinovero wrote:
> == 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 ex
Hello,
We just released Hibernate Search 5.8.0.Beta3, with easier analyzer
configuration, AWS compatibility and DI integration.
You can find more information about 5.8.0.Beta3 on our blog:
http://in.relation.to/2017/06/13/hibernate-search-5-8-0-Beta3/
Yoann Rodière
Hibernate NoORM Team
yo...@hi
Hello,
We just released Hibernate Search 5.8.0.Beta4, with AWS integration and
various bugfixes.
We expect this to be the last 5.8.0 Beta, so be sure to check it out and
give us some feedback before the feature freeze!
You can find more information about 5.8.0.Beta4 on our blog:
http://in.relati
Kudos to you! I'm slowly beginning to understand what a pain such work can
be... Nice to have a reminder that this work can ultimately be rewarded ;)
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 19 July 2017 at 16:44, Guillaume Smet wrote:
> Hi,
>
> So, as we are leaning towards fi
> This build on CI seems stuck since yesterday:
Yes, there was a race condition that I fixed before leaving on Friday.
Sorry I didn't realize this build was still running.
> Also I noticed a huge amount of log output: "121,741 KB". Do you really
> need all that output for each build? Esp. given t
Hello,
We just released Hibernate Search 5.8.0.CR1, with performance improvements
and various bugfixes.
This is the last step before 5.8 is released. Be sure to check it out so
you can share your thoughts with us before the release!
You can find more information about 5.8.0.CR1 on our blog:
http
Hi all,
We just published three bugfix releases of Hibernate Search: 5.5.8.Final,
5.6.3.Final and 5.7.2.Final.
Please see the blog for more details:
http://in.relation.to/2017/08/24/hibernate-search-5-5-8-and-5-6-3-and-5-7-2/
Thanks,
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
__
Hi Gail,
We have a fix on the Hibernate Search side and I confirmed the fix should
not involve any retro-compatibility issue, so we can treat this issue as
non-blocking for the ORM release.
Thanks,
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 4 September 2017 at 14:23, Guillaume Sm
Hey,
About Search, true, the information is somewhat hidden in many blog posts.
I'm not sure the roadmap is the right place, though, since we probably want
the format to be different for past and future releases: information for
past releases is typically more precise and more verbose, with code
e
e at the same level of roadmap, and
>> linking to it both from the main Search menu and the roadmap?
>>
>> +1 for Yoann's proposal to re-introduce the compatibility matrix
>> (there was one ~6 years ago). I also had proposed to reintroduce it
>> more recently, and wa
describing the family?
>
> Thanks,
> Sanne
>
>
> On 8 September 2017 at 13:53, Yoann Rodiere wrote:
> > Hey,
> >
> > I pushed an update to staging. I only converted the "Search" part for
> now.
> > What changes:
> >
> > The _data fo
stions:
>> - could the two links we have for each release on search/releases/ on
>> two separate lines? Or something else to make it clear that there are
>> two linkes.
>> - Regarding the "Compatibility matrix", the header line (the one in
>> black) .
Hibernate NoORM Team
yo...@hibernate.org
On 8 September 2017 at 16:44, Yoann Rodiere wrote:
> Steve,
>
> If I understood correctly, the main difference between what I did and what
> you want is you don't want a "hub" pointing to different versions, you want
> to red
Hello all,
I just noticed that our IDEA codestyle configuration files have specific
rules about how to organize imports, whereas the Eclipse ones don't.
The most noticeable difference: organizing imports in Eclipse puts static
imports at the top, while in IDEA they end up at the bottom. But there
code from failing: we're not going to reformat half the code
>> base to satisfy aesthetics.
>>
>> Perhaps we could have separate sets of rules, some stricter to be
>> applied on new modules; their impact would be limited but even having
>> one module with strict rules
org
On 12 September 2017 at 11:45, Sanne Grinovero wrote:
> On 12 September 2017 at 10:42, Yoann Rodiere wrote:
> >> Fundamentally no IDE will ever produce exactly the same code so you
> >> need to learn control your primal lust for perfection and remember
> >&
rm maintained much, I think latest like you
> proposed makes it more neutral. You could even just name them Series
> - The migration guide should probably be referenced from each individual
> series page.
> - the matrix does not scale very well to that many versions.
> - in th
nate.org
On 13 September 2017 at 11:48, Sanne Grinovero wrote:
> On 13 September 2017 at 10:41, Emmanuel Bernard
> wrote:
> > On Tue 17-09-12 13:50, Yoann Rodiere wrote:
> >>>
> >>>
> >>> - Releases speaks less than downloads, Where do I download Hib
13 September 2017 at 10:51, Yoann Rodiere wrote:
>>
>>> It's more the number of columns, what if you add more version, should I
>>>> scroll horizontally? Also releeases tend to be shown vertically with
>>>> version in desc order. This model breaks a
Hello everyone,
We just released Hibernate Search 5.8.0.Final. Hibernate Search now
integrates with all version of Elasticsearch from 2.0 to 5.6!
Check out our blog for more information about this release:
http://in.relation.to/2017/09/14/hibernate-search-5-8-0-Final/
Yoann Rodière
Hibernate No
ersonally prefer to have this as part of the
> > series info
> >
> > I think the individual series pages are missing a key piece of
> > information... the "synopsis" of that series. I guess partially this
> fits
> > under "what's new"
> &g
No answer? So I guess I can merge it whenever I want? :-)
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 19 September 2017 at 08:36, Yoann Rodiere wrote:
> So, following the comments and a discussion on Hangouts on Friday, I
> worked a bit more, and I just pushed what will hop
Ok, this will never end... It was good to merge less than 24h ago and now
you're arguing against the very point of this work: provide users with more
information regarding each series, so that they know what's new. (see the
first email by Emmanuel)
Please make concrete, exhaustive proposals. From
Aaaand it's merged.
I tried to clean up release YAML files as much as possible for every
project, adding missing files as necessary.
You may want to add some content to each project, most notably to the
"what's new" section of each series, but also to the compatibility matrix
of each series. I up
;push" the version.
>
> Say we want to prune 5.7 - not being in your above list - people will
> still want to be able to find it when upgrading from 5.6 -> 5.8
>
> Thanks,
> Sanne
>
> >
> > BTW tools has a Downloads link, not Releases.
> >
> > Emma
t the top ;)
Anyone against it?
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 28 September 2017 at 09:42, Yoann Rodiere wrote:
> So the order would be:
>
> * Compatibility
> * Documentation
> * How to get it
> * What's new
> * Migrate
> * Releases in
+1. Either we properly mirror our tweets/blog posts to G+, or we stop
advertising that account.
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 28 September 2017 at 11:51, Guillaume Smet
wrote:
> Hi,
>
> We have a couple of Google+ links here and there on the website.
>
> I was think
What's in the matrix is up to each project. You can remove content by
editing the .yml file for each series, and removing elements from site.yml
under projects.orm.integrations.
I'd argue that moving away from the matrix for ORM just because Java
compatibility is "not enough" will force us to add a
Hi,
Thanks Guillaume for stepping up to explain this. I should have done it but
I guess I forgot :)
> You just need to create it for a major.
> It's this page: http://hibernate.org/orm/releases/5.2/ presenting the
> whole
> major.
I think there's a confusion between major, minor an micro here.
Looks great! Thanks for all the good work.
Two suggestions:
- Add a button to display the menu on mobile
- Do not display the author's picture on mobile, or display it on a
separate row. I think it's currently responsible for the minimal screen
width being relatively high, which will
t.
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 2 October 2017 at 11:12, Guillaume Smet wrote:
> On Mon, Oct 2, 2017 at 9:12 AM, Yoann Rodiere wrote:
> > Add a button to display the menu on mobile
>
> I don't think it has much value on in.relation.to. That&
Hello everyone,
We just released Hibernate Search 5.8.1.Final, with several
Elasticsearch-related fixes.
Check out our blog for more information about this release:
http://in.relation.to/2017/10/04/hibernate-search-5-8-1-Final/
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
As you may have understood, the subject of the previous email was wrong.
The version we just released is indeed 5.8.1.Final and not 5.8.0.Final.
Apologies for the confusion.
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 4 October 2017 at 09:31, Yoann Rodiere wrote:
> He
Hush, it's a sensitive topic :) Let's just say it's on purpose, and it
could have been... harsher. The current style is already a compromise.
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 4 October 2017 at 13:22, Hardy Ferentschik wrote:
> Hi,
>
> I like the new layout and navigati
Hi all,
We just published three bugfix releases of Hibernate Search: 5.6.4.Final
and 5.7.3.Final and 5.8.2.Final.
Please see the blog for more details: http://in.relation.
to/2017/10/26/hibernate-search-5-6-4-and-5-7-3-and-5-8-2/
Thanks,
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
__
Steve, Robert,
The link to the room is different for guests: https://www.hipchat.
com/gRRHYZZvB
I just tested it, it works.
It also tends to be re-generated each time there's a security breach at
Atlassian, but that's another story... :)
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
O
about HipChat. I hope
> that's a thing improved in Stride.
>
> @Yoann, could you adjust the info on http://hibernate.org/community/ to
> the room link you provided?
>
> 2017-10-27 15:41 GMT+02:00 Yoann Rodiere :
>
>> Steve, Robert,
>>
>> The link to the room is
Indeed it would make sense to allow custom type names, in particular in ES
5 and below.
In Elasticsearch 6, you can only have one type per index. The main impact
is that we will have to choose between two solutions:
1. Either we continue as before (multiple types per index), but we
somehow
> I think we should just change the behavior of calling EMF#close on a closed
EMF.
> Any application that happens to be relying on us no-op'ing
> this call can easily change that to protect the call with an `#isOpen`
check.
Mentioning this just in case: the javadoc for the AutoCloseable interface
Hello,
We just released Hibernate Search 5.9.0.Beta1, with a new JSR 352
integration adding a mass indexing job with a resume-after-failure feature !
Check out our blog for more information about this release:
http://in.relation.to/2017/11/27/hibernate-search-5-9-0-Beta1/
Yoann Rodière
Hibernat
Seems like the right thing to do. I'm just concerned about the license. Is
it identical?
Some people might be upset to get a new dependency pulled "automatically"
if it has a stricter license...
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 13 December 2017 at 13:10, Sanne Grinovero
Same here, compositions don't seem to be a reasonable use case. And even if
users provide a custom bean registry, they could just implement their
specific behavior for a few specific case, then retrieve another
implementations on their own and delegate to it however they want.
Overriding the servic
t;>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole
>>>> wrote:
>>>>
>>>>> Thanks for the replies. So unless we hear otherwise from anyone else,
>>>>> I will plan on supporting just one DI container.
>>>>>
>>>>&
e Ebersole
>>>>> wrote:
>>>>>
>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven Central?
>>>>>> It was there last week, but is no longer there...
>>>>>>
>>>>>> On Thu, Dec 14, 2
Dec 14, 2017 at 7:44 AM Steve Ebersole
> wrote:
>
>> But your answer above does not answer my question ;)
>>
>> I still have no idea how to go from name+Class -> bean.
>>
>>
>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere
>> wrote:
>>
>>&g
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 inte
messages.
>
> If that's not doable *or a priority* then all we can do is try to make
> it clear enough that there will be limitations and hopefully describe
> these clearly. Some of such limitations might be puzzling as you
> describe.
>
>
>
> On 20 December 2017 at 12:
enterprise.inject.spi.InjectionTarget)?
>>
>>
>> On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere
>> wrote:
>>
>>> Here is how it should work from what I understand (adapted from an
>>> implementation in Search, which has slightly different requi
d do that in our integration today?
>
> On Thu, Dec 21, 2017, 1:53 AM Yoann Rodiere wrote:
>
>> Hi,
>>
>> Following our conversations on HipChat and the various changes you
>> implemented (thanks!), I tested the current implementation. There were a
>> few
1 - 100 of 345 matches
Mail list logo
